VLAN Assignment with CoA
This post is focused on Change of Authorisation packets, and specifically VLAN assignment.
The reason why I’m looking into CoA today is because of a specific scenario. We have many WLCs where we are using multiple VLANs within an interface group. We are looking to implement a solution where if a client is deemed uncompliant, they receive a CoA and are moved to a special VLAN. Once the client is compliant, it will be moved back to the original VLAN – hopefully, the default interface on the SSID.
What I hope for is that we can return a CoA with no VLAN ID, the client will be assigned to the default interface group on the SSID, and can continue to operate. I don’t think this will work, and thus the investigation begins…
The RADIUS RFC (RFC 2865) does not provide a method to change the characteristics of a RADIUS session. This is a critical part of 802.1x, where sessions need to be terminated or changed on demand. RFC5176 was created to address this requirement.
There are two types of packets defined in RFC5176,
Disconnect Packets: Cause a user session to be terminated immediately
Change of Authorisation Packets: Change the user’s session in some way
Any CoA request must be acknowledged. Each packet is sent via UDP port 3799. A CoA packet consists of the following fields:
Code: Identifies the type of RADIUS packet being sent, 1 octet
Identifier: Helps match requests and responses, 1 octet
Length: Indicates the length of the packet, 2 octets
Authenticator: Used to authenticate the reply from the RADIUS server, 16 octets
Attributes: Contains 0 or more attributes, varies in length. With CoA packets, this field is mandatory. If the device does not support a particular attribute, it will respond with a NACK specifying error code 401 or 407, along with the attribute which is unsupported.
The following attributes are used for dynamic VLAN assignment, and are allowed in Access-Request and Access-Accept packets:
When these attributes are used, any existing attributes of the same category are replaced. Or, the VLAN ID will be changed. These attributes are not allowed to appear in Access-Reject, Access-Challenge, Accounting-Request, Accounting-Response packets.
The Tunnel-Type will be set to 1 (IPv4), the Tunnel-Medium-Type will be set to 13, and the Tunnel-Private-Group-ID will be required and set to the VLAN ID. More detail on this at the bottom of the post.
This means that it is mandatory to enter the VLAN ID when using Dynamic VLAN Assignment through CoA. The only other logical option is to use disconnect packets (something for another day).
This is the value of the VLAN ID. According to RFC2868,
“The Tunnel-Private-Group-ID Attribute MAY be included in the Access-Request packet if the tunnel initiator can predetermine the group resulting from a particular connection and SHOULD be included in the Access-Accept packet if this tunnel session is to be treated as belonging to a particular private group.”
|1||Point-to-Point Tunneling Protocol (PPTP)|
|2||Layer Two Forwarding (L2F)|
|3||Layer Two Tunneling Protocol (L2TP)|
|4||Ascend Tunnel Management Protocol (ATMP)|
|5||Virtual Tunneling Protocol (VTP)|
|6||IP Authentication Header in the Tunnel-mode (AH)|
|7||IP-in-IP Encapsulation (IP-IP)|
|8||Minimal IP-in-IP Encapsulation (MIN-IP-IP)|
|9||IP Encapsulating Security Payload in the Tunnel-mode (ESP)|
|10||Generic Route Encapsulation (GRE)|
|11||Bay Dial Virtual Services (DVS)|
|13||Virtual LANs (VLAN)|
|ID||Tunnel Medium Types|
|6||802 (includes all 802 media plus Ethernet “canonical format”)|
|8||E.164 (SMDS, Frame Relay, ATM)|
|10||X.121 (X.25, Frame Relay)|
|15||E.164 with NSAP format subaddress|
References / Links: