INS_RLXE4GE24MODMS_REV– 20 Dec 2017 PAGE 141
INSTALLATION AND OPERATION MANUAL
RLXE4GE24MODMS
TECH SUPPORT: 1.888.678.9427
Admin State
If NAS is globally enabled, this selection controls the port’s authentication mode. The following modes are available:
Force Authorized
In this mode, the switch will send one EAPOL Success frame when the port link comes up, and any client on the port will be allowed
network access without authentication.
Force Unauthorized
In this mode, the switch will send one EAPOL Failure frame when the port link comes up, and any client on the port will be disallowed
network access.
Port-based 802.1X
In the 802.1X-world, the user is called the supplicant, the switch is the authenticator, and the RADIUS server is the authentication server.
The authenticator acts as the man-in-the-middle, forwarding requests and responses between the supplicant and the authentication
server. Frames sent between the supplicant and the switch are special 802.1X frames, known as EAPOL (EAP Over LANs) frames. EAPOL
frames encapsulate EAP PDUs (RFC3748). Frames sent between the switch and the RADIUS server are RADIUS packets. RADIUS packets
also encapsulate EAP PDUs together with other attributes like the switch’s IP address, name, and the supplicant’s port number on the
switch. EAP is very flexible, in that it allows for different authentication methods, like MD5-Challenge, PEAP, and TLS. The important
thing is that the authenticator (the switch) doesn’t need to know which authentication method the supplicant and the authentication
server are using, or how many information exchange frames are needed for a particular method. The switch simply encapsulates the
EAP part of the frame into the relevant type (EAPOL or RADIUS) and forwards it.
When authentication is complete, the RADIUS server sends a special packet containing a success or failure indication. Besides
forwarding this decision to the supplicant, the switch uses it to open up or block traffic on the switch port connected to the supplicant.
Note: Suppose two backend servers are enabled and that the server timeout is configured to X seconds (using the AAA
configuration page), and suppose that the first server in the list is currently down (but not considered dead). Now, if the
supplicant retransmits EAPOL Start frames at a rate faster than X seconds, then it will never get authenticated, because the switch
will cancel on-going backend authentication server requests whenever it receives a new EAPOL Start frame from the supplicant.
And since the server hasn’t yet failed (because the X seconds haven’t expired), the same server will be contacted upon the next
backend authentication server request from the switch. This scenario will loop forever. Therefore, the server timeout should be
smaller than the supplicant’s EAPOL Start frame retransmission rate.
Single 802.1X
In port-based 802.1X authentication, once a supplicant is successfully authenticated on a port, the whole port is opened for network
traffic. This allows other clients connected to the port (for instance through a hub) to piggy-back on the successfully authenticated client
and get network access even though they really aren’t authenticated. To overcome this security breach, use the Single 802.1X variant.
Single 802.1X is really not an IEEE standard, but features many of the same characteristics as does port-based 802.1X. In Single
802.1X, at most one supplicant can get authenticated on the port at a time. Normal EAPOL frames are used in the communication
between the supplicant and the switch. If more than one supplicant is connected to a port, the one that comes first when the port’s
link comes up will be the first one considered. If that supplicant doesn’t provide valid credentials within a certain amount of time,
another supplicant will get a chance. Once a supplicant is successfully authenticated, only that supplicant will be allowed access.
This is the most secure of all the supported modes. In this mode, the Port Security module is used to secure a supplicant’s MAC
address once successfully authenticated.
Multi 802.1X
In port-based 802.1X authentication, once a supplicant is successfully authenticated on a port, the whole port is opened for network
traffic. This allows other clients connected to the port (for instance through a hub) to piggy-back on the successfully authenticated client
and get network access even though they really aren’t authenticated. To overcome this security breach, use the Multi 802.1X variant.
Multi 802.1X is really not an IEEE standard, but features many of the same characteristics as does port-based 802.1X. Multi 802.1X
is – like Single 802.1X – not an IEEE standard, but a variant that features many of the same characteristics. In Multi 802.1X, one
or more supplicants can get authenticated on the same port at the same time. Each supplicant is authenticated individually and
secured in the MAC table using the Port Security module.
In Multi 802.1X it is not possible to use the multicast BPDU MAC address as destination MAC address for EAPOL frames sent from the
switch towards the supplicant, since that would cause all supplicants attached to the port to reply to requests sent from the switch.
Instead, the switch uses the supplicant’s MAC address, which is obtained from the first EAPOL Start or EAPOL Response Identity frame
sent by the supplicant. An exception to this is when no supplicants are attached. In this case, the switch sends EAPOL Request Identity
frames using the BPDU multicast MAC address as destination – to wake up any supplicants that might be on the port.
The maximum number of supplicants that can be attached to a port can be limited using the Port Security Limit Control functionality.
MAC-based Auth.
Unlike port-based 802.1X, MAC-based authentication is not a standard, but merely a best-practices method adopted by the industry. In
MAC-based authentication, users are called clients, and the switch acts as the supplicant on behalf of clients. The initial frame (any kind
of frame) sent by a client is snooped by the switch, which in turn uses the client’s MAC address as both username and password in the
subsequent EAP exchange with the RADIUS server. The 6-byte MAC address is converted to a string on the following form “xx-xx-xx-xx-
xx-xx”, that is, a dash (-) is used as separator between the lower-cased hexadecimal digits. The switch only supports the MD5-Challenge
authentication method, so the RADIUS server must be configured accordingly.
When authentication is complete, the RADIUS server sends a success or failure indication, which in turn causes the switch to open
up or block traffic for that particular client, using the Port Security module. Only then will frames from the client be forwarded on
the switch. There are no EAPOL frames involved in this authentication, and therefore, MAC-based Authentication has nothing to
do with the 802.1X standard.
The advantage of MAC-based authentication over port-based 802.1X is that several clients can be connected to the same port (e.g.
through a 3rd party switch or a hub) and still require individual authentication, and that the clients don’t need special supplicant
software to authenticate. The advantage of MAC-based authentication over 802.1X-based authentication is that the clients don’t need
special supplicant software to authenticate. The disadvantage is that MAC addresses can be spoofed by malicious users – equipment
whose MAC address is a valid RADIUS user can be used by anyone. Also, only the MD5-Challenge method is supported. The maximum
number of clients that can be attached to a port can be limited using the Port Security Limit Control functionality.
