White Rabbit Switch 802.1X MAC Authentication

Introduction

This is a standard feature of 'normal' network switches from Cisco, HP, ... and involves a remote Radius server. Once a node with a MAC gets connected to an access port, the switch asks the Radius server which returns the VID for the nodes' MAC. Ingress frames on that port will then be tagged with that VID. If the node is not allowed to connect, the ports gets isolated.

NB: Here is a GSI specific How-To

Requirements

General

• a 'daemon' runs within the busybox of the WRS management CPU
• the daemon contacts the radius server via the management port (eth0)
• the daemon requires credentials to authenticate itself to the radius server(s) (it does a shared secret between switch and server)

Procedure

Figure: 802.1X state machine simplified for a White Rabbit Switch. Shown are states (boxes) and transitions (edges). Filled boxes change port configuration. A transition to link down is possible for any state (not shown). For details see text.

The figure above depicts a state machine for a White Rabbit switch working as a network access server (NAS) following simplified IEEE 802.1X, with

• max sessions = 1 and
• username = password = mac-address.

States

• link down; everything (re)starts from here
• auth-vlan; port has not been authenticated. Used to pass traffic between device and switch
• in progress; authentication has been triggered, further traffic is ignored. Daemon is talking with radius server using mac address of ingress packet as username and password.
• unauth-vlan; authentication resulted in access denied. Port is isolated.
• default-vlan; authentication completed with access granted. No further information was returned.
• vlan x; authentication completed with access granted. A vlan "x" has been returned

Transitions

• link up; resets port to a starting configuration which is auth-vlan, clears all authentication sessions and waits
• trigger; the first ingress frame is used to trigger mac based authentication. Note: 802.1X knows multiple authentication mechanism. Others not required
• timeout; all radius server time out. Return to starting configuration after a configuratble delay (minutes)
• denied; reply from radius server denies access. Isolate port.
• granted; reply from radius server grants access.
• granted, vlan x; reply from radius server grants access and provides vlan configuration.
• from any state transition to link down is possible. This is a reset.
• final states unauth-vlan, default-vlan, vlan x can transit to link down. Nothing else. No reauthentication. Note: a 'normal' switch has the concept of expiring authentication. Not required for timing.

Important

• WRS 802.1X does not change configuration of rules for routing and filtering
• WRS 802.1X does not act on trunk ports
• WRS 802.1X only acts on access ports
  • the tool does not change configuration of ports regarding egress-frames
  • the tool only acts on the PVID of ports regarding ingress-frames
  • even if a port is in state unauth-vlan, WR-PTP with a connected node is not affected (it still works)

Other

• there is no strict requirement on an upper time for authentication; timing receivers always talk PTP
• only monitor (and handle authentication for) ports that are configured to use 802.1X (for example via port-mask)
• authenticated ports can only change authentication via link-down followed by link-up
• radius servers
  1. redundancy: multiple servers are supported
  2. when contacting: pick any, wait for timeout (defaults about five seconds), pick next
  3. if all servers time out, then transit to state link down and start all over
  4. to speed up the next authentication, remember the last server that has been contacted successfully

Monitoring

The switch monitors the ports configured for configure to use 802.1X. Proposal: monitor all ports for which all of the following conditions are fulfilled

• port is configured as "access" port
• ... AND ...
• port defined in the port-mask 0x00000..0x3ffff (the port-mask is set when the daemon is started) *

Debug and Status Information

• the CLI rvlan-status tells us a list of monitored ports, their states and other debug information
• verbose mode
  • verbose mode is enable/disabled by the CLI rvlan-debug
  • if enabled, debug information is written to /var/log/syslog
  • changing verbose mode restarts the daemon

Parameters

The following parameters are required.

• 'daemon'; the 802.1X daemon is started
• 'credentials'; credentials to connect to the radius server. If multiple servers are configured, it is assumed the credentials are identical.
• 'server list'; list of radius servers. Can be one or two servers.
• 'timeout'; timeout used for contacting a radius server (fixed value, not configurable)
• 'default-vlan'; see above, use the same value for all ports (CH: 'normal' switch this is configurable per port, but not required here)
• 'auth-vlan'; see above, use the same value for all ports (CH: 'normal' switch this is configurable per port, but not required here)
• 'unauth-vlan'; see above, use the same value for all ports (CH: 'normal' switch this is configurable per port, but not required here)
• 'ports'; parameter for CLI: mask 0x00000... 0x3ffff defines which ports shall be monitored

The configuration is done via kconfig items in /wr/etc/dot-config

parameter	kconfig item	default value	remark
daemon	CONFIG_RVLAN_DAEMON	n	if 'n', other parameters have no effect
credentials	CONFIG_RVLAN_RADIUS_SECRET	N/A
server list	CONFIG_RVLAN_RADIUS_SERVERS	N/A
timeout	N/A	N/A	fixed value, not configurable
default-vlan	CONFIG_RVLAN_OBEY_DOTCONFIG	n	if 'y', the value from CONFIG_VLANS_PORTXX_VID is used
auth-vlan	CONFIG_RVLAN_AUTH_VLAN	4094
unauth-vlan	CONFIG_RVLAN_NOAUTH_VLAN	4094
ports	CONFIG_RVLAN_PMASK	'-1', all ports	port 1 is bit 0, port 2 is bit 1, ....

Table: How-to configure the parameters via dot-config.

Status and Documentation

• the official documentation is available on OHWR [link!]
  • it contains further details on the state machine, implementation and How-To
  • snapshot of documentation
• caveats
  • only --pvid is set, no action is performed on the routing table
  • during WRS boot, it may take 1-2 seconds for the tool to be active. 'Forbidden' nodes connected to ports may succeed in sending a few frames to the network.
  • when using default vlan (CONFIG_RVLAN_OBEY_DOTCONFIG=y), the VID returned the radius server is ignored and access is granted. Hence all nodes known to the radius server will get access (but only if the node sends LLDP or PTP messages, otherwise WRS 802.1X will not 'see' the node).

-- DietrichBeck, ChristophHandel - 15 Oct 2020