Background about RFC 3580's VLAN Assignment upon 802.1x Authentication

[FAQ_User]

Article ID: 7312

Protocols/Features
Radius
Tunnel

Standards
RFC 3580
RFC3580
802.1x

Symptoms
"Tunnel-Type"
"Tunnel-Medium-Type"
"Tunnel-Private-Group-ID"

Cause
This article reproduces only the Abstract and Tunnel Attributes sections of RFC3580, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines".

The rationale is to provide background regarding what a growing number of Enterasys products are now supporting: the ability to VLAN-assign a 802.1x Supplicant (user) at the time of Authentication (5532). This is implemented by means of the following Radius Tunnel Attributes: Tunnel-Type=13 (VLAN), Tunnel-Medium-Type=6 (802), Tunnel-Private-Group-ID=<VlanID>.

Here is a list of these products as of June 14 2006:

• Matrix E1, firmware 3.05.09 and higher
• Matrix N-Series (DFE), firmware 5.31.17 and higher
• Matrix V2, firmware 2.5.1.1 and higher
• RBT3K-xG (AP3000), firmware 2.1.1 and higher
• SecureStack C2, firmware 3.02.30 and higher
• SecureStack B2, firmware 1.01.25 and higher
• SecureStack A2, firmware 1.01.20 and higher

To determine the degree of RFC 3580 support on a given hardware product, see that product's latest firmware release notes.

Solution

Abstract

This document provides suggestions on Remote Authentication Dial In
User Service (RADIUS) usage by IEEE 802.1X Authenticators. The
material in this document is also included within a non-normative
Appendix within the IEEE 802.1X specification, and is being
presented as an IETF RFC for informational purposes.

3.31. Tunnel Attributes

Reference [RFC2868] defines RADIUS tunnel attributes used for
authentication and authorization, and [RFC2867] defines tunnel
attributes used for accounting. Where the IEEE 802.1X Authenticator
supports tunneling, a compulsory tunnel may be set up for the
Supplicant as a result of the authentication.

In particular, it may be desirable to allow a port to be placed
into a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based
on the result of the authentication. This can be used, for example,
to allow a wireless host to remain on the same VLAN as it moves
within a campus network.

The RADIUS server typically indicates the desired VLAN by including
tunnel attributes within the Access-Accept. However, the IEEE
802.1X Authenticator may also provide a hint as to the VLAN to be
assigned to the Supplicant by including Tunnel attributes within
the Access-Request.

For use in VLAN assignment, the following tunnel attributes are
used:

Tunnel-Type=VLAN (13)
Tunnel-Medium-Type=802
Tunnel-Private-Group-ID=VLANID

Note that the VLANID is 12-bits, taking a value between 1 and 4094,
inclusive. Since the Tunnel-Private-Group-ID is of type String as
defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer
value is encoded as a string.

When Tunnel attributes are sent, it is necessary to fill in the Tag
field. As noted in [RFC2868], section 3.1:

The Tag field is one octet in length and is intended to
provide a means of grouping attributes in the same packet
which refer to the same tunnel. Valid values for this field
are 0x01 through 0x1F, inclusive. If the Tag field is unused,
it MUST be zero (0x00).

For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint,
Tunnel-Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-
ID or Tunnel-Server-Auth-ID attributes (but not Tunnel-Type,
Tunnel-Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag
field of greater than 0x1F is interpreted as the first octet of the
following field.

Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X
Authenticators that may support tunneling but not VLANs), it is
only necessary for tunnel attributes to specify a single tunnel. As
a result, where it is only desired to specify the VLANID, the tag
field SHOULD be set to zero (0x00) in all tunnel attributes. Where
alternative tunnel types are to be provided, tag values between
0x01 and 0x1F SHOULD be chosen.

See also: RFC2868 and RFC2867.