Interface Policies

802.1X Server Port Authentication

IEEE 802.1X is an IEEE Standard for network port-based Network Access Control. It is part of the IEEE 802.1 group of networking protocols. It provides an authentication mechanism to devices wishing to attach to a LAN.

IEEE 802.1X defines the encapsulation of the Extensible Authentication Protocol (EAP) over IEEE 802, which is known as "EAP over LAN" or EAPOL.

802.1X authentication involves three parties: a supplicant, an authenticator, and an authentication server. The supplicant is a client device (such as a server) that wishes to attach to the LAN. The term 'supplicant' is also used interchangeably to refer to the software running on the client that provides credentials to the authenticator. The authenticator is a network device which provides a data link between the client and the network and can allow or block network traffic between the two, such as an Ethernet switch or wireless access point; and the authentication server is typically a trusted server that can receive and respond to requests for network access, and can tell the authenticator if the connection is to be allowed, and various settings that should apply to that client's connection or setting. Authentication servers typically run software supporting the RADIUS and EAP protocols. In some cases, the authentication server software may be running on the authenticator hardware.

The authenticator acts as a security guard to a protected network. The supplicant (i.e., client device) is not allowed access through the authenticator to the protected side of the network until the supplicant’s identity has been validated and authorized. With 802.1X port-based authentication, the supplicant must initially provide the required credentials to the authenticator - these will have been specified in advance by the network administrator and could include a user name/password or a permitted digital certificate. The authenticator forwards these credentials to the authentication server to decide whether access is to be granted. If the authentication server determines the credentials are valid, it informs the authenticator, which in turn allows the supplicant (client device) to access resources located on the protected side of the network.

Extensions to 802.1X can also allow the authentication server to pass port-configuration options to the authenticator. An example is using RADIUS value-pair attributes to pass a VLAN ID, allowing the supplicant access to one of several VLANs.

(Source: Wikipedia, revised by Apstra)

You can manage 802.1X configuration on network devices with 802.1X server port authentication, a collection of interface policy settings.

802.1X interface policy is supported on Junos (as a Tech Preview) and Arista EOS physical network devices only. Juniper Evolved does not at this time support this feature.

Note:

802.1X interface policy on Junos has been classified as a Juniper Apstra Technology Preview feature. These features are "as is" and voluntary use. Juniper Support will attempt to resolve any issues that customers experience when using these features and create bug reports on behalf of support cases. However, Juniper may not provide comprehensive support services to Tech Preview features.

For additional information, refer to the Juniper Apstra Technology Previews page or contact Juniper Support.

This policy setting enables the network to require L2 servers in a blueprint to authenticate to a RADIUS server before being provided access to the network.

The network operator may require clients to authenticate using EAP-TLS, Certificates, simple username & password, or MAC Authentication bypass.

Note:

Support for encryption protocols, certificates, EAP, is negotiated between RADIUS supplicant and RADIUS server, and is not controlled by the switch.

After authentication occurs, a RADIUS server may optionally set a VLAN ID attribute at authentication time to move the supplicant into a defined VLAN, known by a leaf-specific VLAN ID.

This section describes the necessary tasks to create Interface Policies to be used with 802.1X server port authentication and dynamic VLAN allocation.

Common Scenarios

The following are some common scenarios for 802.1X port authentication.

• Device supports 802.1X, credentials and VLAN are configured in Radius
• Device supports 802.1X, but credentials are not configured in Radius
• Device does not support 802.1X, but the device MAC address is configured in Radius
• Device does not support 802.1X, and device MAC address is not configured in Radius

802.1X Interface Policy Workflow

1. Create virtual networks (e.g. Data VLAN, Fallback VLAN, Dynamic VLAN)
2. Create AAA servers
3. Create 802.1X interface policy
4. Assign ports and fallback VLANs

Create Virtual Networks for Interfaces

Create virtual networks for the interface policy per the table below. We suggest creating these virtual networks with a consistent VLAN ID among all leaf devices (instead of using a resource pool). For more information about creating VLANs, see Virtual Networks.

Parameter	Description
Data VLAN (assigned to ports)	Interfaces will have 802.1X configuration if at least one VLAN is assigned to the port. If a port does not have any VLANs assigned, 802.1X configuration will not be rendered on the interface. The interface will be configured as a routed port.
Dynamic VLAN (optional, assigned to leaf devices, not ports)	The RADIUS server itself optionally chooses the VLAN ID dynamically when the user (supplicant) is authenticated and authorized. Apstra software does not have control over Dynamic VLAN assignment. This decision is made by RADIUS configuration, not by the switch configuration.
Fallback VLAN (optional, assigned to leaf devices, not ports)	Fallback VLAN can be assigned to the user (supplicant) in case of authentication failure. For fallback, the VLAN is controlled by the switch configuration. A RADIUS dynamic VLAN or fallback VLAN must exist on the switch, but there is no requirement to bind any endpoints to that VLAN. It only needs to exist on the switch.

Create AAA Server for Interface Policy

Create the AAA server. For more information, see AAA Servers (Blueprint).

Create 802.1x Interface Policy

You must create the policy before you can assign interfaces or fallback VLANs to it.

1. From the blueprint, navigate to Staged > Polices > Interface Policies and click Create Interface Policy.
2. Enter a name and select 802.1x from the drop-down list.
3. Select the Port Control.
   • dot1x enabled - Requires ports to authenticate EAPOL before being given access to the network.
   • Deny access - Completely blocks the port; no network access is permitted. No other parameters are needed. Example: as a quarantine configuration to quickly deactivate ports that may be infected.
4. Select the Host Mode.
   • Multi-host** (default) - Allows all MAC addresses on the port to authenticate after the first successful authorization. After the first host deauthorizes, all MACs on the port are de-authenticated.
   • Single-host - Permits a single host to authenticate; all other MACs are not permitted.
5. If you want to enable MAC Auth Bypass on Arista EOS, check the Enabled? box. Enabling MAC auth bypass allows a switch to send the MAC address to the RADIUS server if the port does not authenticate within the authentication timeout period. MAC Auth bypass (MAB) requests are only sent if the client does not respond to RADIUS requests, or if the client fails authentication.
   Note:

   MAC Auth bypass must be configured along with 802.1X port control.

   CAUTION:

   MAC auth bypass failure behavior may be different between switch vendors and major switch models.

6. Enter Re-auth Timeout (optional) to configure a time period (seconds). Re-authentication timeout causes the switch to request any clients to re-authenticate to the network after the timeout expires. This also re-triggers MAC Auth bypass.

   If re-authentication timeout is not configured, then no related configuration is rendered on the switch. This means the switchport will be whatever the OS vendor default is. If a value is configured, 802.1X re-authentication will be enabled on the port, and a time value will be configured.

7. Click Create to create the interface policy and return to the table view.

Assign Ports and Fallback VNs to Interface Policy

This steps adds interfaces or dynamic VLANs to the interface policy.

1. From the blueprint, navigate to Staged > Polices > Interface Policies, select the interface policy name and scroll down to the Assigned To section.
2. Assign ports and interfaces: Click leaf names to expand interfaces, then click ports and interfaces to assign them. Note that you cannot assign ports that are assigned to conflicting policies.
3. Assign fallback VN: Assigning the fallback virtual network is leaf-specific. To re-use the fallback on multiple leaf devices, you have to assign it to each leaf. Any VN that is assigned to the leaf may be used as a fallback virtual network, there are no restrictions.
4. After the policy is configured, the settings are now visible, including interfaces those settings apply to.
   Note:

   AAA, Dot1x, and Dot1x interface configurations are now pushed to the leaf devices. The following is a part of sample config rendered for Arista EOS switch.