Dynamic ACLs in Authentication
After successful authentication, different network policies can be applied to restrict the way the client accesses network resources. The 802.1X authentication and MAC authentication implementations support dynamically applying IPv4 ACLs and IPv6 ACLs to a port, based on information received from an authentication server.
When a client or supplicant is authenticated, the authentication server (the RADIUS server) sends the authenticator (the RUCKUS ICX device) a RADIUS Access-Accept message that grants the client access to the network. The RADIUS Access-Accept message contains attributes set for the user in the user profile for 802.1X authentication or the device profile for MAC authentication on the RADIUS server.
ACL Filters Downloaded from RADIUS
The Access-Accept message received from the RADIUS authentication server may include Filter-ID 11 as an attribute, in which case the name or number of an ACL already configured on the ICX device can be applied to the Flexible authentication session. The Access-Accept message received from the RADIUS authentication server may also contain the RADIUS-assigned filter attribute Foundry-NAS-Ipv4-Filter-Rule (Filter-id 12) or Foundry-NAD-IPv6-Filter-Rule (Filter-id 13), in which case, the RUCKUS ICX device can use a filter statement included with the attribute to apply an IPv4 or IPv6 ACL to the authenticated port. The RADIUS-assigned ACL filter statement is often referred to as a downloadable ACL, or dACL. The applied dACL can be an extended IPv4 ACL or an IPv6 ACL.
A dACL, like an ACL specified by a Filter-ID 11 attribute, is applied to the port for as long as the client is connected to the network. The applied ACL is removed from the port when the client logs out, the port goes down, or the MAC session ages out.
It is possible for an Access-Accept message received from the RADIUS authentication server to contain multiple RADIUS-assigned attributes (a combination of Filter-id 11, Foundry-NAS-Ipv4-Filter-Rule, or Foundry-NAS-IPv6-Filter-Rule attributes). When a Filter-id 11 attribute containing an ACL name or number and a Foundry-NAS-Ipv4-Filter-Rule or Foundry-NAS-IPv6-Filter-Rule dACL are present in the same RADIUS Access-Accept message, the Filter-id 11 content is disregarded.
The VSAs listed in the following table support downloadable ACL (dACL) filter statements.
RUCKUS VSAs for RADIUS-Downloadable ACLs
| Attribute Name | Attribute ID | Data Type | Description |
|---|---|---|---|
| Foundry-NAS-Ipv4-Filter-Rule | 12 | string | Includes an IPv4 ACL filter statement that is received and programmed on the ICX device for the duration of the RADIUS session. |
| Foundry-NAS-Ipv6-Filter-Rule | 13 | string | Includes an IPv6 ACL filter statement that is received and programmed on the ICX device for the duration of the RADIUS session. |
The VSAs should be added into the RADIUS server as new attributes by importing an updated Foundry .dictionary file. The .dictionary file is available at the following URL:
https://github.com/redBorder/freeradius/blob/master/share/dictionary.foundry
The following examples are RADIUS-assigned attributes that contain ACL filter statements. The same IPv4 or IPv6 ACL filter is programmed on the ICX device for the relevant session. The user can send multiple filters by repeating the VSA ID followed by a complete filter-rule statement.
Considerations for Downloadable ACLs Configured on a RADIUS Server
The following restrictions and considerations apply to dynamic IPv4 extended ACLs and IPv6 ACLs downloaded to an ICX device from a RADIUS server:
- A maximum of 45 filter statements, including both IPv4 and IPv6, can be sent.
- ACLS downloaded from RADIUS can be applied only to inbound traffic. Outbound ACLs are not supported.
- IPv4 standard ACLs are not supported for RADIUS download.
- The authenticated user session clears when an ICX device lacks sufficient TCAM space availability. The session might remain in an authenticated state while the IP address is learned and TCAM programming starts. It then clears, especially in cases involving large downloadable or dynamic ACLs.
- In creating ACL statements for delivery from RADIUS, the user must provide complete ACL filter statements, with no abbreviations.
- ACLs with mirror or log options are not supported.
- Domain names and traffic policy options are not supported in ACL filters. Use matching IP addresses instead.
- The following well-known protocol or port names are supported in RADIUS-downloaded ACLs: FTP, FTP-data, SSH, Telnet, SMTP, DNS, HTTP, GPPintp, POP2, SFTP, SQLserv, BGP, LDAP, SSL, TFTP, SNMP, BOOTPC, and BOOTPS. Any other protocol or port names not mentioned above are not supported in RADIUS-downloaded ACLs and their use may result in an error state. For non-supported well-known protocols, please use port numbers in the filter statements.
- RADIUS-assigned ACL filter statements are given priority if an ACL ID is sent in the same RADIUS Accept message.