LevelOne GEP-2671 Manual - Page 221

MAC-based Auth., RADIUS-Assigned QoS Enabled, based 802.1X

Page 221 highlights

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 bestpractices 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 "xxxx-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 MD5Challenge 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.  RADIUS-Assigned QoS Enabled : When RADIUS-Assigned QoS is both globally enabled and enabled (checked) on a given port, the switch reacts to QoS Class information carried in the RADIUS Access-Accept packet transmitted by the RADIUS server when a supplicant is successfully authenticated. If present and valid, traffic received on the supplicant's port will be classified to the given QoS Class. If (re-)authentication fails or the RADIUS Access-Accept packet no longer carries a QoS Class or it's invalid, or the supplicant is otherwise no longer present on the port, the port's QoS Class is immediately reverted to the original QoS Class (which may be changed by the administrator in the meanwhile without affecting the RADIUS-assigned). This option is only available for single-client modes, i.e. • Port-based 802.1X • Single 802.1X RADIUS attributes used in identifying a QoS Class: Refer to the written documentation for a description of the RADIUS attributes needed in order to successfully identify a QoS Class. The User-Priority-Table attribute defined in RFC4675 forms the basis for identifying the QoS Class in an Access-Accept packet. 207

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270

207
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.
RADIUS-Assigned QoS Enabled :
When RADIUS-Assigned QoS is both globally enabled and enabled (checked) on a given
port, the switch reacts to QoS Class information carried in the RADIUS Access-Accept
packet transmitted by the RADIUS server when a supplicant is successfully authenticated.
If present and valid, traffic received on the supplicant's port will be classified to the given
QoS Class. If (re-)authentication fails or the RADIUS Access-Accept packet no longer
carries a QoS Class or it's invalid, or the supplicant is otherwise no longer present on the
port, the port's QoS Class is immediately reverted to the original QoS Class (which may be
changed by the administrator in the meanwhile without affecting the RADIUS-assigned).
This option is only available for single-client modes, i.e.
• Port
-based 802.1X
• Single 802.1X
RADIUS attributes used in identifying a QoS Class:
Refer to the written documentation for a description of the RADIUS attributes needed in
order to successfully identify a QoS Class. The User-Priority-Table attribute defined in
RFC4675 forms the basis for identifying the QoS Class in an Access-Accept packet.