draft-ietf-radext-ieee802-00.txt   draft-ietf-radext-ieee802-01.txt 
Networking Working Group Paul Congdon Networking Working Group Paul Congdon
INTERNET-DRAFT Mauricio Sanchez INTERNET-DRAFT Mauricio Sanchez
<draft-ietf-radext-ieee802-00.txt> Hewlett-Packard Company <draft-ietf-radext-ieee802-01.txt> Hewlett-Packard Company
A. Lior A. Lior
10 July 2005 Bridgewater Systems 17 January 2006 Bridgewater Systems
F. Adrangi F. Adrangi
Intel Intel
Bernard Aboba Bernard Aboba
Microsoft Microsoft
VLAN, Priority, and Filtering Attributes VLAN, Priority, and Filtering Attributes
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
skipping to change at page 1, line 37 skipping to change at page 1, line 37
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January, 10 2006. This Internet-Draft will expire on July, 17 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. All rights reserved. Copyright (C) The Internet Society 2006. All rights reserved.
Abstract Abstract
In certain scenarios it is desirable to limit user access using In certain scenarios it is desirable to limit user access using
dynamic VLANs, filters or redirection. This documents proposes dynamic VLANs, reprioritization, filters, or redirection. This
additional attributes for this purpose, for use with the Remote document proposes additional attributes for this purpose, for use
Authentication Dial In User Server (RADIUS). The attributes with the Remote Authentication Dial In User Server (RADIUS). The
described in this document are expected to be useful in a variety attributes described in this document are expected to be useful in
of environments, including enterprise and service provider a variety of environments, including enterprise and service
scenarios. provider scenarios.
Table of Contents Table of Contents
1. Introduction........................................... 3 1. Introduction........................................... 3
1.1. Terminology...................................... 3 1.1. Terminology...................................... 4
1.2. Requirements Language............................ 4 1.2. Requirements Language............................ 4
2. Overview............................................... 5 1.3. Capability Advertisement ........................ 5
2.1. Capability Advertisement ........................ 6 1.4. Attribute Interpretation......................... 5
2.2. Attribute Interpretation......................... 6 2. RADIUS Authentication.................................. 5
3. RADIUS Authentication.................................. 7 2.1. Egress-VLANID.................................... 5
3.1. Egress-VLANID.................................... 7 2.2. Ingress-Filters.................................. 6
3.2. Ingress-Filters.................................. 8 2.3. Egress-VLAN-Name................................. 7
3.3. VLAN-Name........................................ 9 2.4. User-Priority-Table.............................. 8
3.4. User-Priority-Table.............................. 10 2.5. NAS-Filter-Rule.................................. 9
3.5. NAS-Filter-Rule.................................. 11 3. RADIUS Accounting...................................... 19
3.6. QoS-Filter-Rule.................................. 18 3.1. Acct-NAS-Filter-Rule............................. 19
4. RADIUS Accounting...................................... 19 4. Table of Attributes.................................... 20
4.1. Acct-NAS-Filter-Rule.............................. 19 5. IANA Considerations.................................... 20
4.2. Acct-EAP-Auth-Method............................. 19 6. Security Considerations................................ 21
5. Table of Attributes.................................... 21 7. References............................................. 21
6. IANA Considerations.................................... 21 7.1 Normative References................................... 21
7. Security Considerations................................ 21 7.2 Informative References................................. 23
7.1. Packet modification or forgery................... 22 Appendix A - Traffic Redirection.............................. 24
7.2. Dictionary Attacks............................... 22 Appendix B - NAS-Filter-Rule Examples......................... 29
7.3. Known Plaintext Attacks.......................... 22 ACKNOWLEDGMENTS............................................... 30
8. References............................................. 23 AUTHORS' ADDRESSES............................................ 30
8.1 Normative References................................... 23 Intellectual Property Statement............................... 31
8.2 Informative References................................. 24 Disclaimer of Validity........................................ 32
Appendix A - Traffic Redirection.............................. 25 Full Copyright Statement ..................................... 32
ACKNOWLEDGMENTS............................................... 29
AUTHORS' ADDRESSES............................................ 29
Intellectual Property Statement............................... 29
Disclaimer of Validity........................................ 30
Full Copyright Statement ..................................... 30
1. Introduction 1. Introduction
Within the confines of RADIUS authentication, authorization, and Within the confines of RADIUS authentication, authorization, and
accounting (AAA) environments, there is a general dearth of accounting (AAA) environments, there is a requirement for
standardized RADIUS attributes to limit user access using dynamic standardized RADIUS attributes to limit user access using dynamic
VLANs, filters or redirection. VLANs, reprioritization, filters or redirection.
For example, in IEEE 802.1X [IEEE8021X] environments, which For example, in IEEE 802.1X [IEEE8021X] environments, which
provides "network port authentication" for IEEE 802 [IEEE802] provides "network port authentication" for IEEE 802 [IEEE802]
media, including Ethernet [IEEE8023], Token Ring and 802.11 media, including Ethernet [IEEE8023] and 802.11 [IEEE80211i]
[IEEE80211i] wireless LANS, there exists a strong desire to wireless LANS, there exists a strong desire to control
control authorization beyond just the untagged VLAN parameter authorization beyond just the untagged VLAN parameter based on
based on tunnel attributes in [RFC2868]. tunnel attributes in [RFC2868] and usage of these in [RFC3580].
This document describes VLAN, filtering and re-direction This document describes VLAN, reprioritization, filtering and
attributes that may prove useful in IEEE 802.1X and a variety of redirection attributes that may prove useful in IEEE 802.1X and a
situations. The attributes defined in this document may be used variety of situations. The attributes defined in this document may
with RADIUS dynamic authorization [RFC3576]. be used with RADIUS dynamic authorization [RFC3576].
The Filter-ID attribute defined in [RFC2865] requires the NAS to The Filter-ID attribute defined in [RFC2865] requires the NAS to
be pre-populated with the desired filters. This may be difficult be pre-populated with the desired filters. This may be difficult
to deploy in roaming scenarios where the home realm may not know to deploy in roaming scenarios where the home realm may not know
what filters have been pre-populated by the local operator. The what filters have been pre-populated by the local operator. The
filtering attributes specified in this document enable explicit filtering attributes specified in this document enable explicit
description of layer 2 and layer 3 filters as well as redirection, description of layer 2 and layer 3 filters as well as redirection,
and therefore extend the filter language described in [RFC3588]. and therefore extend the filter language described in [RFC3588].
User traffic redirection is supported with or without tunneling. User traffic redirection is supported with or without tunneling.
Tunneling support is provided using the tunnel attributes defined Tunneling support is provided using the tunnel attributes defined
in [RFC2868]. Redirection of traffic in mid-session may break in [RFC2868]. Redirection of traffic in mid-session may break
applications. applications.
IEEE 802.1X-2004 [IEEE8021X] provides "network port
authentication" for IEEE 802 [IEEE802] media, including Ethernet
[IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i].
While [RFC3580] enables support for VLAN assignment based on the While [RFC3580] enables support for VLAN assignment based on the
tunnel attributes defined in [RFC2868], it does not provide tunnel attributes defined in [RFC2868], it does not provide
support for the full set of VLAN functionality. The VLAN support for a more complete set of VLAN functionality as defined
attributes defined in this document provide support within RADIUS by [IEEE8021Q]. The VLAN attributes defined in this document
analogous to the MIB variables supported in [IEEE-802.1Q]. In provide support within RADIUS analogous to the management
addition, this document enables support for a wider range of variables supported in [IEEE8021Q] and MIB objects defined in
[IEEE8021X] configuration. [RFC2674]. In addition, this document enables support for a wider
range of [IEEE8021X] configurations.
1.1. Terminology 1.1. Terminology
In this document when we refer to Blocking of IP traffic we mean In this document when we refer to Blocking of IP traffic we mean
Filtering of IP traffic. Additionally, this document uses the Filtering of IP traffic. Additionally, this document uses the
following terms: following terms:
Access Point (AP)
A Station that provides access to the distribution services
via the wireless medium for associated Stations.
Association
The service used to establish Access Point/Station mapping
and enable Station invocation of the distribution system
services.
Authenticator Authenticator
An authenticator is an entity that require authentication An authenticator is an entity that require authentication
from the supplicant. The authenticator may be connected to from the supplicant. The authenticator may be connected
the supplicant at the other end of a point-to-point LAN to the supplicant at the other end of a point-to-point
segment or 802.11 wireless link. LAN segment or 802.11 wireless link.
Authentication server Authentication server
An authentication server is an entity that provides an An authentication server is an entity that provides an
authentication service to an authenticator. This service authentication service to an authenticator. This service
verifies from the credentials provided by the supplicant, verifies from the credentials provided by the supplicant,
the claim of identity made by the supplicant. the claim of identity made by the supplicant.
Hot-lining Hot-lining
Blocking and redirection of users traffic is known as hot- Blocking and redirection of users traffic is known as
lining of accounts. In this document, hot-lining is used as hot-lining of accounts. In this document, hot-lining is
the motivation for these attributes and an illustration of used as the motivation for these attributes and an
how they would be used. However, the attributes may be used illustration of how they would be used. However, the
together or separately to provide other features. attributes may be used together or separately to provide
other features.
Port Access Entity (PAE)
The IEEE8021.X protocol entity associated with a physical or
virtual (802.11) Port. A given PAE may support the
IEEE8021.X protocol functionality associated with the
Authenticator, Supplicant or both.
Redirection Redirection
Refers to an action taken by the NAS to redirect the user's Refers to an action taken by the NAS to redirect the
traffic to an alternate location. user's traffic to an alternate location.
Station (STA)
Any device that contains an IEEE 802.11 conformant medium
access control (MAC) and physical layer (PHY) interface to
the wireless medium (WM).
Supplicant Supplicant
A supplicant is an entity that is being authenticated by an A supplicant is an entity that is being authenticated by
authenticator. The supplicant may be connected to the an authenticator. The supplicant may be connected to the
authenticator at one end of a point-to-point LAN segment or authenticator at one end of a point-to-point LAN segment
802.11 wireless link. or 802.11 wireless link.
1.2. Requirements Language 1.2. Requirements Language
In this document, several words are used to signify the In this document, several words are used to signify the
requirements of the specification. The key words "MUST", "MUST requirements of the specification. The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or An implementation is not compliant if it fails to satisfy one or
more of the must or must not requirements for the protocols it more of the must or must not requirements for the protocols it
implements. An implementation that satisfies all the must, must implements. An implementation that satisfies all the must, must
not, should and should not requirements for its protocols is said not, should and should not requirements for its protocols is said
to be "unconditionally compliant"; one that satisfies all the must to be "unconditionally compliant"; one that satisfies all the must
and must not requirements but not all the should or should not and must not requirements but not all the should or should not
requirements for its protocols is said to be "conditionally requirements for its protocols is said to be "conditionally
compliant". compliant".
2. Overview 1.3. Capability Advertisement
As described in the Introduction section, it may be desirable to a
control user's access to network resources (e.g. the Internet)
with greater standardized explicitness than what current RADIUS
attributes provide. In this section we will examine these
requirements in more detail.
Besides IEEE 802.1X networks, there is a corollary need within
Internet Service Provider (ISP) environments for standardized
authorization attributes. From time to time, an ISP requires to
restrict a user's access to the Internet and redirect their
traffic to an alternate location. For example, the user maybe on
a prepaid plan and all the resources have been used up. In this
case the ISP would block the user's access to the Internet and
redirect them to a portal where the user can replenish their
account. Another example where the ISP would want to restrict
access and redirect a user that was involved in some fraudulent
behavior. Again the ISP would want to block the user's access to
the Internet and redirect to a portal where they can inform the
user as to their state and allow them to inform the user of their
concerns and potentially rectify the situation.
The ability to block user's traffic is required at service
initiation and once service has been established. These
capabilities must also be available across access technologies and
various business scenarios. For example, the ability to block and
redirect traffic is required for TCP users, cell phone users, WiFi
users. As well, this capability must work whether the user is in
their home network or roaming in a visited network which may or
may not have a direct roaming relationship with the user's home
network.
Blocking access refers to setting up access control rules at the
NAS such that when the user initiates IP traffic, the NAS examines
the set of rules associated with the service granted to the user.
These rules determine what traffic is allowed to proceed through
the NAS and what traffic will be blocked. Today this capability
is supported in RADIUS and is configurable during service
establishment and mid-service via the Filter-Id(11) attribute. To
use Filter-Id to control access to network resources the rules
need to be configured apriori at each NAS. Filter-Id(11) is used
in an Access-Accept to specify the name of the filter rule(s) to
apply to this session. To effect a change mid-service
(dynamically), the Filter-Id(11) is included in a Change-of-
Authorization (COA) packet as described in [RFC3676]. Upon
receiving the Filter-Id(11) the NAS starts to apply the rules
specified by the Filter-Id(11).
As pointed out by [NASREQ] the use Filter-Id is not roaming
friendly and it is recommended that instead one should use NAS-
Filter-Rule(TBD) AVP. For this reason, this document introduces
NAS-Filter-Rule(TBD) to RADIUS.
2.1. Capability Advertisement
RADIUS does not currently define a method by which a NAS can RADIUS does not currently define a method by which a NAS can
advertise its capabilities and in many instances, it would be advertise its capabilities and in many instances, it would be
desirable for the home network to know what capabilities are desirable for the home network to know what capabilities are
supported by the NAS to ensure proper operational behavior. The supported by the NAS to ensure proper operational behavior. The
attributes defined in this document are intended to be used to attributes defined in this document are intended to be used to
enforce policy by the NAS. If a NAS does not recognize these enforce policy by the NAS. If a NAS does not recognize these
attributes it will most likely ignore them and the desired policy attributes it will most likely ignore them and the desired policy
will not be enforced. A method for the NAS advertising the will not be enforced. A method for the NAS advertising the
capability to support these attributes would help the RADIUS capability to support these attributes would help the RADIUS
server understand if the intended policies can be enforced. As a server understand if the intended policies can be enforced. As a
result, the attributes in this document, in particular NAS-Filter- result, the attributes in this document, in particular NAS-Filter-
Rule(TBD), can benefit from capability advertisement, if Rule(TBD), can benefit from capability advertisement, if
available. available.
2.2 Attribute Interpretation 1.4 Attribute Interpretation
Unless otherwise noted in the individual description of an Unless otherwise noted in the individual description of an
attribute contained herein, a NAS that conforms to this attribute contained herein, a NAS that conforms to this
specification and receives an Access-Accept message that contains specification and receives an Access-Accept message that contains
an attribute from this document that it does not recognize or an attribute from this document that it cannot apply MUST
cannot apply MUST interpret this though an Access-Reject had been interpret this though an Access-Reject had been sent and MUST
sent and MUST terminate the session. If accounting is enabled on terminate the session. If accounting is enabled on the NAS, it
the NAS, it MUST generate an Accounting-Request(Stop) message upon MUST generate an Accounting-Request(Stop) message upon session
session termination. termination.
Similarly, if a NAS conforming to this specification receives a Similarly, if a NAS conforming to this specification and also
CoA message that contains an attribute from this document that it conforming to RFC 3576 [RFC3576] receives a CoA message that
does not recognize or cannot apply, it MUST NOT terminate the contains an attribute from this document that it cannot apply, it
session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101) MUST NOT terminate the session and MUST generate a CoA-NAK packet
set to "Unsupported Attribute"(401). If accounting is enabled on with ERROR-CAUSE(101) set to "Unsupported Attribute"(401). If
the NAS, it MUST NOT generate an Accouting-Request(Stop) message accounting is enabled on the NAS, it MUST NOT generate an
in such instances. Accounting-Request(Stop) message in such instances.
3. RADIUS Attributes 2. RADIUS Authentication
This specification introduces seven new RADIUS attributes. This specification introduces five new RADIUS authentication
attributes.
3.1. Egress-VLANID 2.1. Egress-VLANID
Description Description
The Egress-VLANID attribute represents an allowed IEEE 802 The Egress-VLANID attribute represents an allowed IEEE 802
Egress VLANID for this port. The Egress-VLANID contains two Egress VLANID for this port. The Egress-VLANID contains two
parts: the first part indicates if the VLANID is allowed for parts: the first part indicates if the VLANID is allowed for
tagged or untagged packets and the second part is the VLANID. tagged or untagged packets and the second part is the VLANID.
Multiple Egress-VLANID attributes can be delivered in an Multiple Egress-VLANID attributes can be delivered in an
authentication response; each attribute adds the specified VLAN authentication response; each attribute adds the specified VLAN
to the list of allowed egress VLANs for the port. to the list of allowed egress VLANs for the port.
The Egress-VLANID attribute is shown below. The fields are The Egress-VLANID attribute is shown below. The fields are
transmitted from left to right: transmitted from left to right:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer | Type | Length | Tag Option | Pad (12-bit)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer(cont.) | Pad | VLANID (12-bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD TBD
Length Length
6 6
Integer Integer
The Integer field is four octets in length. The format of the The Integer field is four octets in length. The format of the
Integer field consists of two parts, the first consuming high- Integer field consists of three parts, the first consuming the
order octet and the second consuming the remaining three lower- high-order octet, the second consuming the subsequent 12-bits,
order octets. The high-order octet field indicates if the and the third consuming the low-order 12-bits. The high-order
VLANID is allowed for tagged or untagged packets. The second octet, the Tag Option, indicates whether the frames on the VLAN
part is the 12-bit 802.1Q VLAN VID value that has been padded are tagged 0x31 or untagged 0x32. The second part is 12-bits of
out to consume the remaining three lower-order octets. A padding. Padding bits MUST be 0 (zero). The third part is the
sample encoding follows: 12-bit [IEEE8021Q] VLAN VID value.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Option | Pad (12-bit) | VLANID (12-bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values for the Tag Option part include:
1 = Tagged
2 = Untagged
Padding bits SHOULD be 0 (zero).
VLANID is the 12-bit 802.1Q-2003 VID value.
3.2. Ingress-Filters 2.2. Ingress-Filters
Description Description
The Ingress-Filters attribute corresponds to Ingress Filter The Ingress-Filters attribute corresponds to Ingress Filter
per-port variable defined in IEEE 802.1Q clause 8.4.5. When per-port variable defined in IEEE 802.1Q clause 8.4.5. When
the attribute has the value "Enabled", the set of VLANs that the attribute has the value "Enabled", the set of VLANs that
are allowed to ingress a port must match the set of VLANs that are allowed to ingress a port must match the set of VLANs that
are allowed to egress a port. Only a single Ingress-Filters are allowed to egress a port. Only a single Ingress-Filters
attribute MAY be sent within an Access-Accept or CoA-Request; attribute MAY be sent within an Access-Accept or CoA-Request;
this attribute MUST NOT be sent within an Access-Request, this attribute MUST NOT be sent within an Access-Request,
Access-Challenge, Access-Reject, or Disconnect-Request. Access-Challenge, Access-Reject, or Disconnect-Request.
The Ingress-Filters attribute is shown below. The fields are
transmitted from left to right:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Integer (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD TBD
Length Length
6 6
Integer Integer
The values include: The values include:
1 - Enabled 1 - Enabled
2 - Disabled 2 - Disabled
3.3. VLAN-Name 2.3. Egress-VLAN-Name
Description Description
Clause 12.10.2.1.3 (a) in [IEEE8021Q] describes the Clause 12.10.2.1.3 (a) in [IEEE8021Q] describes the
administratively assigned VLAN Name associated with a VLAN ID administratively assigned VLAN Name associated with a VLAN ID
defined within an 802.1Q bridge. The VLAN-Name attribute defined within an 802.1Q bridge. The Egress-VLAN-Name attribute
represents an allowed VLAN for this port. It works similar to represents an allowed VLAN for this port. It works similar to
the Egress-VLANID attribute except that the VLAN-ID itself is the Egress-VLANID attribute except that the VLAN-ID itself is
not specified or known, rather the VLAN name is used to not specified or known, rather the VLAN name is used to
identify the VLAN within the system. identify the VLAN within the system.
The VLAN-Name attribute contains two parts; the first part The Egress-VLAN-Name attribute contains two parts; the first
indicates if frames on the VLAN for this port are to be part indicates if frames on the VLAN for this port are to be
represented in tagged or untagged format, the second part is represented in tagged or untagged format, the second part is
the VLAN name. the VLAN name.
Multiple VLAN-Name attributes can be delivered in an Multiple Egress-VLAN-Name attributes can be delivered in an
authentication response; each attribute adds the named VLAN to authentication response; each attribute adds the named VLAN to
the list of allowed egress VLANs for the port. the list of allowed egress VLANs for the port.
The Egress-VLAN-Name attribute is shown below. The fields are
transmitted from left to right:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Option | VLAN-Name
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VLAN-Name (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD TBD
Length Length
>= 4 >= 4
String String
The first octet of this string indicates whether the frames on The first octet of this string, the tag option field, indicates
the VLAN are tagged 0x01 or Untagged 0x02. The remaining whether the frames on the VLAN are tagged 0x31 or untagged
octets represent the VLAN Name as defined in 802.1Q-2003 clause 0x32. The remaining octets of the VLAN-Name field represent
12.10.2.1.3 (a). UTF-8 encoded 10646 characters are the VLAN Name as defined in 802.1Q-2003 clause 12.10.2.1.3 (a).
recommended, but a robust implementation SHOULD support the [RFC3629] UTF-8 encoded 10646 characters are recommended, but a
field as undistinguished octets. robust implementation SHOULD support the field as
undistinguished octets.
3.4. User-Priority-Table 2.4. User-Priority-Table
Description Description
IEEE 802.1D clause 7.5.1 discusses how to regenerate (or re- [IEEE802.1D] clause 7.5.1 discusses how to regenerate (or re-
map) user priority on frames received at a port. This per-port map) user priority on frames received at a port. This per-port
configuration enables a bridge to cause the priority of configuration enables a bridge to cause the priority of
received traffic at a port to be mapped to a particular received traffic at a port to be mapped to a particular
priority. The management variables are described in clause priority. The management variables are described in clause
14.6.2.2. 14.6.2.2.
This attribute represents the IEEE 802 prioritization that will This attribute represents the IEEE 802 prioritization that will
be applied to packets arriving at this port. There are eight be applied to packets arriving at this port. There are eight
possible user priorities, according to the IEEE 802 standard. possible user priorities, according to the [IEEE802] standard.
The User-Priority-Table attribute is shown below. The fields
are transmitted from left to right:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD) | Length | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD TBD
Length Length
10 10
String String
The table, expressed as an 8 octet string, maps the incoming The table, expressed as an 8 octet string, maps the incoming
priority (if one exists - the default is 0) into one of seven priority (if one exists - the default is 0) into one of eight
regenerated priorities. The format of this attribute is an regenerated priorities. The format of this attribute is an
eight byte octet string, where the first octet maps to incoming eight byte octet string, where the first octet maps to incoming
priority 0, the second octet to incoming priority 1, etc. The priority 0, the second octet to incoming priority 1, etc. The
values in each octet represent the regenerated priority of the values in each octet represent the regenerated priority of the
packet. packet.
It is thus possible to either remap incoming priorities to more It is thus possible to either remap incoming priorities to more
appropriate values; or to honor the incoming priorities; or to appropriate values; or to honor the incoming priorities; or to
override any incoming priorities, forcing them to all map to a override any incoming priorities, forcing them to all map to a
single chosen priority. single chosen priority.
The [IEEE 8021D] specification, Annex G, provides a useful The [IEEE 8021D] specification, Annex G, provides a useful
description of traffic type - traffic class mappings. description of traffic type - traffic class mappings.
3.5. NAS-Filter-Rule 2.5. NAS-Filter-Rule
Description Description
The NAS-Filter-Rule attribute is derived from the Diameter The NAS-Filter-Rule attribute is derived from the Diameter
IPFilterRule and enables the provisioning of base encapsulation IPFilterRule and enables provisioning of base encapsulation
(Layer 2), Internet Protocol (Layer 3-4), and HTTP (Layer 5+) (Layer 2) rules, Internet Protocol (Layer 3-4) rules, and HTTP
filter rules and Internet Protocol and HTTP redirect rules on (Layer 5+) rules on the NAS by the RADIUS server. Compared to
the NAS by the RADIUS server. Diameter's IPFilterRule, NAS-Filter-Rule is a superset in
functionality, but is largely based on the same syntax
foundations.
When specifying a base encapsulation filter rule, NAS-Filter- For each rule and depending on the rule type, the NAS can be
Rule processes packets based on the following information that instructed to take a single action as follows:
is associated with it:
Rule Type Allowable rule action
------------------- ---------------------
Base Encapsulation filter, tunnel
Internet Protocol filter, tunnel
HTTP filter, redirect
When specifying a base encapsulation rule, NAS-Filter-Rule
processes packets based on the following information that is
associated with it:
Direction (in and/or out) Direction (in and/or out)
Base encapsulation type Base encapsulation type
Source and destination MAC address (possibly masked) Source and destination MAC address (possibly masked)
When specifying an Internet Protocol filter or tunnel rule, For a base encapsulation rule, the filter action entails having
NAS-Filter-Rule processes packets based on the following the NAS permit (i.e. forward) or deny (i.e. block) a user's
information that is associated with it: traffic. The tunnel action entails having the NAS forward user
traffic to or from a named tunnel that has been established per
[RFC2868].
When specifying an Internet Protocol rule, NAS-Filter-Rule
processes packets based on the following information that is
associated with it:
Direction (in and/or out) Direction (in and/or out)
Source and destination IP address (possibly masked) Source and destination IP address (possibly masked)
Protocol Protocol
Source and destination port (lists or ranges) Source and destination port (lists or ranges)
TCP flags TCP flags
IP fragment flag IP fragment flag
IP options IP options
ICMP types ICMP types
When specifying an HTTP filter or redirect rule, NAS-Filter- For an Internet Protocol rule, the filter action entails having
Rule process packets based on the following information that is the NAS permit (i.e. forward) or deny (i.e. block) a user's
associated with it: traffic. The tunnel action entails having the NAS forward user
traffic to or from a named tunnel that has been established per
[RFC2868].
When specifying an HTTP rule, NAS-Filter-Rule process packets
based on the following information that is associated with it:
HTTP URL HTTP URL
Source and destination IP address (possibly masked) Source and destination IP address (possibly masked)
For an HTTP rule, the filter action entails having the NAS
permit (i.e. forward) or deny (i.e. block) a user's [RFC2616]
request message. For a deny action, the NAS MAY respond to the
request message with a code 403 (Forbidden) response in
accordance with [RFC2616]. For a redirect action the NAS SHOULD
respond to the user's request with a code 302 (Found) response
in accordance with [RFC2616].
For the HTTP redirection action, it is also possible to have
redirection automatically removed by including a redir-cnt
count parameter along with the rule. The rule will be removed
from the active rule set when the rule matches redir-cnt number
of times. Upon removal from the active rule set, traffic is no
longer evaluated against this rule.
It should be noted that an HTTP filter or redirect rule is only It should be noted that an HTTP filter or redirect rule is only
useful with plain-text HTTP and not HTTPS. Redirection or useful with plain-text HTTP and not HTTPS. Redirection or
filtering of HTTPS is outside the scope of this document. filtering of HTTPS is outside the scope of this document.
As per the requirements of RFC 2865, Section 2.3, if multiple As per the requirements of RFC 2865, Section 2.3, if multiple
NAS-Filter-Rule attributes are contained within an Access- NAS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder NAS-Filter-Rule packet. RADIUS proxies MUST NOT reorder NAS-Filter-Rule
attributes. attributes.
The RADIUS server can return multiple NAS-Filter-Rule The RADIUS server can return multiple NAS-Filter-Rule
attributes in an Access-Accept or CoA-Request packet. Where attributes in an Access-Accept or CoA-Request packet. Where
more than one NAS-Filter-Rule attribute is included, it is more than one NAS-Filter-Rule attribute is included, it is
assumed that the attributes are to be concatenated to form a assumed that the attributes are to be concatenated to form a
single filter list. Furthermore, the concatenated filter list single filter list. Furthermore, if the list contains different
must abide to the following rules of precedence and ordering: types of rules, they MUST appear in the following order: flush
rules, base encapsulation tunnel rules, base encapsulation
1) A flush rule MUST appear before all other rule types. filter rules, IP tunnel rules, HTTP redirect rules, IP filter
rules, and HTTP filter rules.
2) Base encapsulation filter rules MUST appear after a
flush rule and before IP tunnel, HTTP redirect, IP
filter, and/or HTTP filter rules.
3) IP tunnel rules MUST appear after any base encapsulation
rules and before any HTTP redirect, IP filter, and/or
HTTP filter rules
4) HTTP redirect rules MUST appear after any IP tunnel
rules and before any IP filter and/or HTTP filter rules.
5) IP filter rules MUST appear after any HTTP redirect
rules and before any HTTP filter rules.
6) HTTP filter rules MUST appear after any other rules.
Rules are evaluated in order, with the first matched rule Rules are evaluated in order, with the first matched rule
terminating the evaluation. Each packet is evaluated once. If terminating the evaluation. Each packet is evaluated once. If
no rule matches, then packet is dropped (implicit deny all). no rule matches, then packet is dropped (implicit deny all).
When an HTTP redirect rule matches, the NAS shall reply to the When an HTTP redirect rule matches, the NAS shall reply to the
HTTP request with an HTTP redirect in accordance with [RFC2616] HTTP request with an HTTP redirect in accordance with [RFC2616]
redirecting traffic to specific URL. redirecting traffic to specific URL.
Filter-ID (11) and NAS-Filter-Rule both define how filters are Filter-ID (11) and NAS-Filter-Rule both define how filters are
to be applied in the NAS. Both are not intended to be used to be applied in the NAS. These attributes are not intended to
concurrently and SHOULD NOT appear in the same RADIUS message. be used concurrently and SHOULD NOT appear in the same RADIUS
Only one type of filtering attribute must be processed. If a message. Only one type of filtering attribute must be
Filter-ID (11) is present, then the NAS-Filter-Rule MUST be processed. If a Filter-ID (11) is present, then the NAS-Filter-
ignored, if present.. Rule MUST be ignored, if present.
The NAS-Filter-Rule attribute is shown below. The fields are The NAS-Filter-Rule attribute is shown below. The fields are
transmitted from left to right: transmitted from left to right:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD) | Length | Text | | Type (TBD) | Length | Text
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Text (cont.) | Text (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD TBD
Length Length
>= 3 >= 3
Text
The text conforms to the following specification:
NAS-Filter-Rule MUST follow the general format:
action [args] dir proto from src to dst [options] Text
action
permit - Allow packets that match the rule. The text conforms to the following ABNF [RFC2234] formatted syntax
specification:
deny - Drop packets that match the rule. ; Start of ABNF description of NAS-Filter-Rule
redirect - Redirect packets that match the rule. rule = (flush-rule / permit-all-rule
/ l2-filter-rule / l2-tunnel-rule
/ ip-filter-rule / ip-tunnel-rule
/ http-filter-rule / http-redir-rule)
rule-delim
tunnel - Tunnel packets that match the rule. ; Flush Rule
flush-rule = "flush"
flush - Remove all previously assigned filter rules. ; Permit all rule
When flush is specified, it can be followed permit-all-rule = "permit inout any from any to any"
by other NAS-Filter attributes. This allows
for an atomic change of authorization with a
single RADIUS message.
args <[redir_cnt] redir_URL|tunnel_id> ; Base encapsulation filter rule
l2-filter-rule = ("permit" / "deny") " "
("in" / "out" / "inout") " "
l2-filter-body [" " log-rule]
l2-filter-body = (l2-proto " from " l2-address " to "
l2-address) / l2-rmon-str
l2-proto = "l2:ether2" [":0x" 1*4HEXDIG]
l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT)
l2-address = ["!"] (macaddr / (macaddr "/" macmask)
/ "any")
macaddr = 2HEXDIG 5("-" 2HEXDIG)
macmask = DIGIT ; 0-9
/ %x31-33 DIGIT ; 10-39
/ "4" %x30-38 ; 40-48
For HTTP redirect rules: ;Base encapsulation tunnel rule
redir_cnt Specifies the number of redirect rule matches l2-tunnel-rule = "tunnel " tunnel-id " "
that should transpire before removing this ("in" / "out" / "inout") " "
rule from the active rule set. Upon removal l2-filter-body [" " log-rule]
from the active rule set, traffic is no
longer evaluated against this rule.
redir_URL An HTTP URL. When the 'redirect' rule matches ;IP Filter Rule
(src/dst), HTTP requests are redirected to ip-filter-rule = ("permit" / "deny") " "
redir_URL address in accordance with ("in" / "out" / "inout") " "
[RFC2616] redirection traffic to specific ("ip" / ip-proto) filter-body
URL. [" " ip-option] [" " log-rule]
ip-proto = d8
ip-address = ["!"] (ipv4-address ["/" ipv4mask] /
ipv6-address ["/" ipv6mask] /
"any" /
"assigned")
ipv4-address = d8 "." d8 "." d8 "." d8
ipv4mask = DIGIT ; 0-9
/ %x31-32 DIGIT ; 10-29
/ "3" %x30-32 ; 30-32
ipv6-address = 1*4HEXDIG 7(":" 1*4HEXDIG)
ipv6mask = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" %x30-31 DIGIT ; 100-119
/ "1" %x32 %x30-38 ; 120-128
tcp-ports = tcp-port *("," tcp-port)
tcp-port = d16 / d16 "-" d16
ip-option = "frag" /
["ipoptions " ["!"] ipopt *("," ["!"] ipopt)]
["tcpoptions " ["!"] tcpopt
*("," ["!"] tcpopt)]
["established"]
["setup"]
["tcpflags " ["!"] tcpflag
*("," ["!"] tcpflag)]
["icmptypes " icmptype *("," icmptype)]
ipopt = "ssrr" / "lsrr" / "rr" / "ts"
tcpopt = "mss" / "window" / "sack" / "ts" / "cc"
tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg"
For IP tunnel rules: icmptype = d8 / d8 "-" d8
tunnel_id A tunnel id. When the 'tunnel' rule matches, / "echo reply" / "destination unreachable"
traffic is redirected over the tunnel with / "source quench" / "redirect"
the specified tunnel_id. Traffic can only be / "echo request" / "router advertisement"
redirected to or from named tunnels that have / "router solicit" / "time-to-live exceeded"
been established per [RFC2868] and named / "IP header bad" / "timestamp request"
using the Tunnel-Assignment-ID attribute / "timestamp reply" / "information request"
described therein. / "information reply"
/ "address mask request"
/ "address mask reply"
dir "in" is from the terminal, "out" is to the ;IP Tunnel Rule
terminal, "inout" is from and to the terminal. ip-tunnel-rule = "tunnel " tunnel-id " "
("in" / "out" / "inout") " "
("ip" / ip-proto) filter-body
[" " ip-option] [" " log-rule]
proto <l2:<ether2[:val]|rmon_str>> type[:val]|ipprot|ip|http> ;HTTP Filter Rule
http-filter-rule= ("permit" / "deny") org-url " "
("in" / "out" / "inout") filter-body
[" " log-rule]
For base encapsulation filter rules: ;HTTP Redirect Rule
"l2" Prefix on any base encapsulation rule to http-redir-rule= "redirect " [redir-cnt " "] redir-url
designate as rule as such. filter-body [" " org-url]
"ether2" keyword means any Ethernet-II (DIX Ethernet) [" " log-rule]
will match. redir-cnt = 1*DIGIT
ether2:val Used to specify an Ethernet-II type by org-url = http_URL
hexadecimal number, whereby "val" is replaced ;Note: Syntax for http_URL defined in
by desired number. Example: "l2:ether2:0x800" ;[RFC2616], section 3.2.2
for IP ethertype (0x0800). redir-url = http_URL
"rmon_str" Used to specify base encapsulation per the
octet string format defined in [RFC2895],
section 4.2. Example: "l2:0.0.0.2.0.0.0.240"
for Netbios over LLC.
For IP filter or tunnel rules: ;Common
"ip" keyword means any IP protocol will match. filter-body = " from " ip-address [" " tcp-ports]
ipprot An IP protocol specified by number. " to " ip-address [" " tcp-ports]
tunnel-id = DQUOTE
*(TEXTDATA
/ ("%" 2HEXDIG)
/ ("\" 1*("\"))
/ ("\" DQUOTE))
DQUOTE
log-rule = "cnt"
For HTTP filter or redirect rules: ;Primitives
"http" keyword used to designate rule as of http rule-delim = LF
type. d8 = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
d16 = DIGIT ; 0-9
/ %x31-35 1*4DIGIT ; 10-59999
/ "6" "4" 3DIGIT ; 60000-64999
/ "6" "5" %x30-34 2DIGIT ; 65000-65499
/ "6" "5" "5" %x30-32 1DIGIT ; 65500-65529
/ "6" "5" "5" "3" %x30-36 ; 65530-65536
TEXTDATA = %x20-21 / %x23-2B / %x2D-7E
src, dst <address/mask> [ports] ; End of ABNF description of NAS-Filter-Rule
For base encapsulation filter rules of "l2:ether2" type, Descriptions of notable fields and keywords follow:
<address/mask> may be specified as:
macaddr An Ethernet MAC address with octet values "permit" Allow packets that match the rule.
separated by a "-". Example: "00-10-A4-23-
19-C0".
macaddr/mask An Ethernet number as above with a mask "deny" Drop packets that match the rule.
width of the form "00-10-A4-23-19-C0/24".
In this case, all MAC addresses from 00-
10-A4-00-00-00 to 00-10-A4-FF-FF-FF will
match. The MAC address MUST NOT have bits
set beyond the mask. The keyword "any" is
00-00-00-00-00-00/0.
The sense of the match can be inverted by "redirect" Redirect packets that match the rule.
preceding an address with the not modifier
(!), causing all other addresses to be
matched instead.
Note: macaddr nor macaddr/mask argument is "tunnel" Tunnel packets that match the rule.
not used for "l2:rmon" type rules. Also,
[ports] optional argument not valid for MAC
filter rules.
For IP filter or tunnel rules, the <address/mask> may be "flush" A flush rule removes all previously assigned
specified as: filter rules. When flush is specified, it can be
followed by other NAS-Filter-Rule attributes. This
allows for an atomic change of authorization with a
single RADIUS message.
ipno An IPv4 or IPv6 number in dotted-quad or "permit inout any from any to any"
canonical IPv6 form. Only this exact IP Special rule that matches against all traffic. This
number will match the rule. allows the implicit deny at the end of a filter
ipno/bits An IP number as above with a mask width of list to be overridden.
the form 1.2.3.4/24. In this case, all IP
numbers from 1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the IP
version and the IP number MUST NOT have bits
set beyond the mask. For a match to occur,
the same IP version MUST be present in the
packet that was used in describing the IP
address. To test for a particular IP
version, the bits part can be set to zero.
The keyword "any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned" is the
address or set of addresses assigned to the
terminal. For IPv4, a typical first rule is
often "deny in ip !assigned"
The sense of the match can be inverted by "in" Is from the terminal.
preceding an address with the not modifier
(!), causing all other addresses to be
matched instead. This does not affect the
selection of port numbers.
With the TCP, UDP and SCTP protocols, optional ports "out" Is to the terminal.
may be specified as:
{port/port-port}[,ports[,...]] "inout" Is from and to the terminal.
The '-' notation specifies a range of ports ipv4-address An IPv4 number in dotted-quad form. Only this
(including boundaries). Fragmented packets that exact IP number will match the rule.
have a non-zero offset (i.e., not the first ipv6-address An IPv6 number in canonical IPv6 form. Only
fragment) will never match a rule that has one this exact IP number will match the rule
or more port specifications. See the frag ipv4-address/ipv4mask
option for details on matching fragmented An IP number with a mask width of the form
packets. 192.0.2.0/24. In this case, all IP numbers from
192.0.2.0 to 192.0.2.255 will match.
options The bit width MUST be valid for the IP version and
For all rule types other than 'flush', there is an the IP number MUST NOT have bits set beyond the
optional argument that can be specified: mask. For a match to occur, the same IP version
Cnt Increments rule hit counter by one every MUST be present in the packet that was used in
time a packet matches on rule. Counters describing the IP address. To test for a
start with a zero value at session start particular IP version, the bits part can be set to
and are reset back to a zero value every zero.
time an authorization change occurs due to
a CoA message.
For IP filter or tunnel rules, there are several "any" Keyword for 0.0.0.0/0 or the IPv6 equivalent.
optional arguments that can be specified:
frag Match if the packet is a fragment and this "assigned" Keyword for the address or set of addresses
is not the first fragment of the datagram. assigned to the terminal. For IPv4, a typical
frag may not be used in conjunction with first rule is often "deny in ip !assigned"
either tcpflags or TCP/UDP port
specifications.
ipoptions spec The sense of the match can be inverted by preceding
Match if the IP header contains the comma an address with the not modifier (!), causing all
separated list of options specified in other addresses to be matched instead. This does
spec. The supported IP options are: not affect the selection of port numbers.
ssrr (strict source route), lsrr (loose tcp-port With the TCP, UDP and SCTP protocols, this field
source route), rr (record packet route) specifies ports to match.
and ts(timestamp). The absence of a
particular option may be denoted with a
'!'.
tcpoptions spec Note: The '-' notation specifies a range of ports
Match if the TCP header contains the comma (including boundaries). Fragmented packets that
separated list of options specified in have a non-zero offset (i.e., not the first
spec. The supported TCP options are: fragment) will never match a rule that has one or
more port specifications. See the "frag" keyword
for details on matching fragmented packets.
mss (maximum segment size), window (tcp log-rule Increments rule hit counter by one every time a
window advertisement), sack (selective packet matches on rule. Counters start with a zero
ack), ts (rfc1323 timestamp) and cc value at session start and are reset back to a zero
(rfc1644 t/tcp connection count). The value every time a successful authorization change
absence of a particular option may be occurs due to a CoA message being received by the
denoted with a '!'. NAS.
established For base encapsulation rules:
TCP packets only. Match packets that have "l2:" Prefix on any base encapsulation rule to designate
the RST or ACK bits set. as rule as such.
setup TCP packets only. Match packets that have "l2:ether2" Keyword means any Ethernet-II (DIX Ethernet) will
the SYN bit set but no ACK bit. match.
tcpflags spec ether2:val Used to specify an Ethernet-II type by hexadecimal
TCP packets only. Match if the TCP header number, whereby "val" is replaced by desired
contains the comma separated list of flags number. Example: "l2:ether2:0x800" for IP ethertype
specified in spec. The supported TCP (0x0800).
flags are:
fin, syn, rst, psh, ack and urg. The l2-rmon-str Used to specify base encapsulation per the octet
absence of a particular flag may be string format defined in [RFC2895], section 4.2.
denoted with a '!'. A rule that contains Example: "l2:0.0.0.2.0.0.0.240" for Netbios over
a tcpflags specification can never match LLC.
a fragmented packet that has a non-zero
offset. See the frag option for details
on matching fragmented packets.
icmptypes types macaddr For base encapsulation filter rules of "l2:ether2"
ICMP packets only. Match if the ICMP type type, the Ethernet MAC address with octet values
is in the list types. The list may be separated by a "-". Example: "00-10-A4-23-19-C0".
specified as any combination of ranges or
individual types separated by commas.
Both the numeric values and the symbolic
values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable macaddr/mask An Ethernet number as above with a mask width of
(3), source quench (4), redirect (5), echo the form "00-10-A4-23-00-00/32". In this case, all
request(8), router advertisement (9), MAC addresses from 00-10-A4-23-00-00 to 00-10-A4-
router solicitation (10), time-to-live 23-FF-FF will match. The MAC address MUST NOT have
exceeded (11), IP header bad (12), bits set beyond the mask. The keyword "any" is
timestamp request (13), timestamp reply 00-00-00-00-00-00/0.
(14), information request (15),
information reply (16), address mask
request (17) and address mask reply (18).
Concise syntax statements for each rule type follow: The sense of the match can be inverted by preceding
an address with the not modifier (!), causing all
other addresses to be matched instead.
A NAS-Filter-Rule expressing a flush of all rules MUST follow Note: macaddr nor macaddr/mask argument is not used
the syntax: for "l2:rmon" type rules.
<flush> For IP rules:
"ip" Keyword means any IP protocol will match.
A NAS-Filter-Rule expressing an base encapsulation filter rule ip-proto An IP protocol specified by number.
MUST follow the syntax:
<permit|deny> <in|out|inout> <l2:<ether2[:val]|rmon_str>> from "frag" Match if the packet is a fragment and this is not
<address/mask> to <address/mask> [options] the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or
TCP/UDP port specifications.
A NAS-Filter-Rule expressing an IP tunnel or filter rule MUST "ipoptions" Match if the IP header contains the comma separated
follow the syntax: list of options specified in spec. The supported
IP options are: ssrr (strict source route), lsrr
(loose source route), rr (record packet route) and
ts(timestamp). The absence of a particular option
may be denoted with a '!'.
<permit|deny|redirect <tunnel <tunnel_id>> <in|out|inout> "tcpoptions" Match if the TCP header contains the comma
<ip|ip_proto> from <address/mask> to <address/mask> [ports] separated list of options specified in spec. The
[options] supported TCP options are:
A NAS-Filter-Rule expressing a HTTP redirect or filter rule mss (maximum segment size), window (tcp window
MUST follow the syntax: advertisement), sack (selective ack), ts (rfc1323
timestamp) and cc (rfc1644 t/tcp connection count).
The absence of a particular option may be denoted
with a '!'.
<permit|deny|redirect> [redir_cnt] <redir_URL> <in|out|inout> "established" TCP packets only. Match packets that have the
from <address/mask> to <address/mask> [options] RST or ACK bits set.
A NAS that is unable to interpret or apply a deny rule MUST "setup" TCP packets only. Match packets that have the SYN
terminate the session. A NAS MAY apply deny rules of its own bit set but no ACK bit.
before the supplied rules, for example to protect the access
device owner's infrastructure.
3.6. QoS-Filter-Rule "tcpflags" TCP packets only. Match if the TCP header contains
the comma separated list of flags specified in
spec. The supported TCP flags are:
Description fin, syn, rst, psh, ack and urg. The absence of a
particular flag may be denoted with a '!'. A rule
that contains a tcpflags specification can never
match a fragmented packet that has a non-zero
offset. See the "frag" option for details on
matching fragmented packets.
The QoS-Filter-Rule attribute enables the provisioning of QoS "icmptypes" ICMP packets only. Match if the ICMP type is in
filters on the NAS by the RADIUS server. The QoS-Filter-Rule the list types. The list may be specified as any
attribute is defined as follows: combination of ranges or individual types separated
by commas. Both the numeric values and the
symbolic values listed below can be used. The
supported ICMP types are:
Type echo reply (0), destination unreachable (3), source
quench (4), redirect (5), echo request(8), router
advertisement (9), router solicitation (10), time-
to-live exceeded (11), IP header bad (12),
timestamp request (13), timestamp reply (14),
information request (15), information reply (16),
address mask request (17) and address mask reply
(18).
TBD For HTTP redirection rules:
redir_cnt Specifies the number of HTTP redirect rule matches
that should transpire before removing this rule
from the active rule set. Upon removal from the
active rule set, traffic is no longer evaluated
against this rule.
Length redir_URL An HTTP URL. When the 'redirect' rule matches
(src/dst and/or org_URL ), HTTP requests are
redirected to redir_URL address in accordance with
[RFC2616] redirection traffic to specific URL.
>=3 org_URL An HTTP URL. Specifies the HTTP URL against which
user HTTP requests will be evaluated. If user HTTP
request matches org_URL, then redirection action is
taken.
Text For base encapsulation and IP tunnel rules:
tunnel_id A tunnel id. When the 'tunnel' rule matches,
traffic is redirected over the tunnel with the
specified tunnel_id. Traffic can only be redirected
to or from named tunnels that have been established
per [RFC2868] and named using the Tunnel-
Assignment-ID attribute described therein.
The Text field contains a QoS filter, utilizing the syntax The tunnel id MUST be encapsulated in double quotes
defined for the QoSFilterRule derived data type defined in and use the following escape functions in case the
[RFC3588], Section 4.3. Note that this definition contained an tunnel id itself contains any quotes:
error, so that the complete syntax is described in the
definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
[Editorial: Is there a need to mention the possibility for For all occurrences of " replace with \"
attribute fragmentation. Dave N. to provide RFC reference that For all occurrences of \ replace with \\
talks about the fragmentation of an AVP >256 over multiple
RADIUS attributes]
The RADIUS server can return multiple QoS-Filter-Rule Example: A tunnel with the name of tunnel "ppp1"
attributes in an Access-Accept or CoA-Request packet. Where would be specified as "tunnel \"pp1\"" within the
more than one QoS-Filter-Rule Rule attribute is included, it is rule.
assumed that the attributes are to be concatenated to form a
single QOS filter.
Whereas the maximum allowable message size in [NASREQ] is A NAS that is unable to interpret or apply a deny rule MUST
greater than RADIUS' maximum allowable message size, it is terminate the session. A NAS MAY apply deny rules of its own
assumed that QOS filters that exceed RADIUS' allowable message before the supplied rules, for example to protect the access
size will be broken into multiple QoS-Filter-Rule attributes by device owner's infrastructure.
the RADIUS server and concatenated back into a single QOS
filter by the NAS.
As per the requirements of RFC 2865, Section 2.3, if multiple 3. RADIUS Accounting
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes.
4. RADIUS Accounting This specification introduces one new RADIUS accounting attribute.
4.1. Acct-NAS-Filter-Rule 3.1. Acct-NAS-Filter-Rule
Description Description
Acct-NAS-Filter-Rule enables a RADIUS client to include NAS- Acct-NAS-Filter-Rule enables a RADIUS client to include NAS-
Filter-Rule[TODO] rule match counters as part of the accounting Filter-Rule[TODO] rule match counters as part of the accounting
message. message.
The Acct-NAS-Filter-Rule attribute is shown below. The fields The Acct-NAS-Filter-Rule attribute is shown below. The fields
are transmitted from left to right: are transmitted from left to right:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String | Type | Length | Counter (64-bits)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont.) Counter (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Counter (cont.) | Text (NAS-Filter-Rule) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD TBD
Length Length
>=3 >=3
String String
The first eight octets of this string are used for a 64-bit The first eight octets of this string are used for a 64-bit
value of the rule counter. The remaining octets are used to value of the rule counter. The remaining octets are used to
specify which filter rule the counter value is for. The rule specify which filter rule the counter value is for. The rule
specification MUST conform to the syntax rules specified for specification MUST conform to the syntax rules specified for
NAS-Filter-Rule[TODO]. NAS-Filter-Rule[TBD].
4.2. Acct-EAP-Auth-Method
Description
Acct-EAP-Auth-Method enables a RADIUS client to include the EAP
method utilized within an accounting packet. The semantics of
this attribute are identical to that of the Acct-EAP-Auth-
Method AVP defined in [DiamEAP], Section 4.1.5. This is a
standard RADIUS attribute.
The Acct-EAP-Auth-Method attribute is shown below. The fields are
transmitted from left to right:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
10
String
The Value field is eight octets. In case of expanded types
defined in [RFC3748] Section 5.7, the least significant 32 bits
contain the Vendor-Type field, and the next 24 bits contain the
Vendor-Id field and 8 bits reserved data, which SHOULD be zero.
5. Table of Attributes 4. Table of Attributes
The following table provides a guide to which attributes may be The following table provides a guide to which attributes may be
found in which kinds of packets, and in what quantity. found in which kinds of packets, and in what quantity.
Access- Access- Access- Access- CoA- Access- Access- Access- Access- CoA-
Request Accept Reject Challenge Req # Attribute Request Accept Reject Challenge Req # Attribute
0 0+ 0 0 0+ TBD Egress-VLANID 0 0+ 0 0 0+ TBD Egress-VLANID
0 0-1 0 0 0-1 TBD Ingress-Filters 0 0-1 0 0 0-1 TBD Ingress-Filters
0 0-1 0 0 0-1 TBD User-Priority-Table 0 0-1 0 0 0-1 TBD User-Priority-Table
0 0+ 0 0 0+ TBD NAS-Filter-Rule 0 0+ 0 0 0+ TBD NAS-Filter-Rule
0 0+ 0 0 0+ TBD QoS-Filter-Rule
Actng- Actng- Actng- Actng-
Request Response # Attribute Request Response # Attribute
0-1 0 TBD Acct-NAS-Filter-Rule 0-1 0 TBD Acct-NAS-Filter-Rule
0-1 0 TBD Acct-EAP-Auth-Method
The following table defines the meaning of the above table The following table defines the meaning of the above table
entries. entries.
0 This attribute MUST NOT be present in packet. 0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in 0+ Zero or more instances of this attribute MAY be present in
the packet. the packet.
0-1 Zero or one instance of this attribute MAY be 0-1 Zero or one instance of this attribute MAY be
present in the packet. present in the packet.
6. IANA Considerations 5. IANA Considerations
This document uses the RADIUS [RFC2865] namespace, see This document uses the RADIUS [RFC2865] namespace, see
<http://www.iana.org/assignments/radius-types>. Allocation of <http://www.iana.org/assignments/radius-types>. Allocation of
seven updates for the section "RADIUS Attribute Types" is seven updates for the section "RADIUS Attribute Types" is
requested. The RADIUS attributes for which values are requested requested. The RADIUS attributes for which values are requested
are: are:
TBD - Egress-VLANID TBD - Egress-VLANID
TBD - Ingress-Filters TBD - Ingress-Filters
TBD - User-Priority-Table TBD - User-Priority-Table
TBD - NAS-Filter-Rule TBD - NAS-Filter-Rule
TBD - QoS-Filter-Rule
TBD - Acct-NAS-Filter-Rule TBD - Acct-NAS-Filter-Rule
TBD - Acct-EAP-Auth-Method 6. Security Considerations
7. Security Considerations
Since this document describes the use of RADIUS for purposes of Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in IEEE 802.1X- authentication, authorization, and accounting in IEEE 802.1X-
enabled networks, it is vulnerable to all of the threats that are nabled networks, it is vulnerable to all of the threats that are
present in other RADIUS applications. For a discussion of these present in other RADIUS applications. For a discussion of these
threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576], threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580].
[RFC3579], and [RFC3580].
Vulnerabilities include:
Packet modification or forgery
Dictionary attacks
Known plaintext attacks
Key management issues
7.1. Packet Modification or Forgery
As noted in [RFC3580], when used with IEEE 802.1X, all RADIUS
packets MUST be authenticated and integrity protected. In
addition, as described in [RFC3579], Section 4.2:
To address the security vulnerabilities of RADIUS/EAP,
implementations of this specification SHOULD support IPsec
[RFC2401] along with IKE [RFC2409] for key management. IPsec
ESP [RFC2406] with non-null transform SHOULD be supported, and
IPsec ESP with a non-null encryption transform and
authentication support SHOULD be used to provide per-packet
confidentiality, authentication, integrity and replay
protection. IKE SHOULD be used for key management.
7.2. Dictionary Attacks
As discussed in [RFC3579] Section 4.3.3, the RADIUS shared secret
is vulnerable to offline dictionary attack, based on capture of
the Response Authenticator or Message-Authenticator attribute. In
order to decrease the level of vulnerability, [RFC2865], Section 3
recommends:
The secret (password shared between the client and the RADIUS
server) SHOULD be at least as large and unguessable as a well-
chosen password. It is preferred that the secret be at least
16 octets.
In addition, the risk of an offline dictionary attack can be
further mitigated by employing IPsec ESP with non-null
transform in order to encrypt the RADIUS conversation, as
described in [RFC3579], Section 4.2.
7.3. Known Plaintext Attacks
Since IEEE 802.1X is based on EAP, which does not support PAP, the This document specifies new attributes that can be included in
RADIUS User-Password attribute is not used to carry hidden user existing RADIUS messages. These messages are protected using
passwords. The hiding mechanism utilizes MD5, defined in existing security mechanisms; see [RFC2865] and [RFC3576] for a
[RFC1321], in order to generate a key stream based on the RADIUS more detailed description and related security considerations.
shared secret and the Request Authenticator. Where PAP is in
use, it is possible to collect key streams corresponding to a
given Request Authenticator value, by capturing RADIUS
conversations corresponding to a PAP authentication attempt using
a known password. Since the User-Password is known, the key stream
corresponding to a given Request Authenticator can be determined
and stored.
The vulnerability is described in detail in [RFC3579], Section The security mechanisms in [RFC2865] and [RFC3576] are primarily
4.3.4. Even though IEEE 802.1X Authenticators do not support PAP concerned with an outside attacker who modifies messages in
authentication, a security vulnerability can still exist where the transit or inserts new messages. They do not prevent an authorized
same RADIUS shared secret is used for hiding User-Password as well RADIUS server or proxy from inserting attributes with a malicious
as other attributes. This can occur, for example, if the same purpose in message it sends.
RADIUS proxy handles authentication requests for both IEEE 802.1X
(which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-
Recv-Key attributes) and GPRS (which may hide the User-Password
attribute).
The threat can be mitigated by protecting RADIUS with IPsec ESP An attacker who compromises an authorized RADIUS server or proxy
with non-null transform, as described in [RFC3579], Section 4.2. can use the attributes defined in this document to influence the
In addition, the same RADIUS shared secret MUST NOT used for both behavior of the NAS in ways that previously may not have been
IEEE 802.1X authentication and PAP authentication. possible. For example, modifications to the VLAN-related
attributes may cause the NAS to permit access to other VLANs that
were intended. To give another example, inserting suitable
redirection rules to the NAS-Filter-Rule attribute may allow the
attacker to eavesdrop or modify packets sent by a legitimate
client.
8. References In general, the NAS cannot know whether the attribute values it
receives from an authenticated and authorized server are well-
intentioned or malicious, and thus it is not possible to
completely protect against attacks by compromised nodes. In some
cases, the extent of the possible attacks can be limited by
performing more fine-grained authorization checks at the NAS.
For instance, a NAS could be configured to accept only certain
VLAN IDs from a certain RADIUS server/proxy, or not to accept any
redirection rules if it is known they are not used in this
environment.
8.1. Normative references 7. References
[RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest 7.1. Normative references
Algorithm", RFC 1321, April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach P., Berners-Lee T., "Hypertext Transfer Protocol L., Leach P., Berners-Lee T., "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2616, June 1999. -- HTTP/1.1", RFC 2616, June 1999.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June
2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
and I. Goyret, "RADIUS Attributes for Tunnel Protocol and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC2895] Bierman, A., Bucci, C., Iddon, R., "Remote Network [RFC2895] Bierman, A., Bucci, C., Iddon, R., "Remote Network
Monitoring MIB Protocol Identifier Reference", RFC Monitoring MIB Protocol Identifier Reference", RFC
2895, August 2000 2895, August 2000
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
Aboba,"Dynamic Authorization Extensions to Remote Aboba,"Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576, Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003. July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J.,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC3580, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko,
J., "Diameter Base Protocol", RFC 3588, September 2003. J., "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter
Network Access Server Application", RFC 4005, August 2005.
[IEEE8021D]
IEEE Standards for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges, IEEE Std 802.1D-2004,
June 2004.
[IEEE8021Q]
IEEE Standards for Local and Metropolitan Area Networks:
Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q, January 1998.
[IEEE8021X] [IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks: IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2004, Port based Network Access Control, IEEE Std 802.1X-2004,
August 2004. August 2004.
[IEEE802.11i] 7.2. Informative references
Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11:Wireless LAN Medium Access Control
(MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security",
June 2004.
8.2. Informative references [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest
Algorithm", RFC 1321, April 1992.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2234] Croker, E., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: [RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A.,
Overview and Architecture, ANSI/IEEE Std 802, 1990. McCloghrie, K., Definitions of Managed Objects
for Bridges with Traffic Classes, Multicast Filtering and
Virtual LAN Extensions", RFC 2674, August 1999.
[IEEE8021Q] [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
IEEE Standards for Local and Metropolitan Area Networks:
Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q, January 1998.
[IEEE8021D] [RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
IEEE Standards for Local and Metropolitan Area Networks: Modifications for Tunnel Protocol Support", RFC 2867, June
Media Access Control (MAC) Bridges, IEEE Std 802.1D-2004, 2000.
June 2004.
[RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC
2607, November 2003.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8023] [IEEE8023]
ISO/IEC 8802-3 Information technology - Telecommunications ISO/IEC 8802-3 Information technology - Telecommunications
And information exchange between systems - Local and And information exchange between systems - Local and
metropolitan area networks - Common specifications - Part metropolitan area networks - Common specifications - Part
3: Carrier Sense Multiple Access with Collision Detection 3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications, (CSMA/CD) Access Method and Physical Layer Specifications,
(also ANSI/IEEE Std 802.3- 1996), 1996. (also ANSI/IEEE Std 802.3- 1996), 1996.
[IEEE80211] [IEEE80211]
Information technology - Telecommunications and information Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN networks - Specific Requirements Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, IEEE Std. 802.11-1999, 1999. Specifications, IEEE Std. 802.11-1999, 1999.
[IEEE80211i]
Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11:Wireless LAN Medium Access Control
(MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security",
June 2004.
Appendix A - Traffic Redirection Appendix A - Traffic Redirection
There are several ways to redirect the user's traffic. Which There are several ways to redirect the user's traffic. Which
method will be used depends on the capabilities available at the method will be used depends on the capabilities available at the
NAS and Service Provider's preference. This Appendix describes NAS and Service Provider's preference. This Appendix describes
various methods to redirect user traffic by using the new various methods to redirect user traffic by using the new
attributes outlined in this document in conjunction with existing attributes outlined in this document in conjunction with existing
attributes, which are: attributes, which are:
1) Tunneling; and 1) Tunneling; and
skipping to change at page 26, line 11 skipping to change at page 24, line 38
an alternate location. Tunneling will typically redirect all of an alternate location. Tunneling will typically redirect all of
the user's traffic for the Service. When tunneling is used to the user's traffic for the Service. When tunneling is used to
redirect all the traffic, then filtering may not be necessary. redirect all the traffic, then filtering may not be necessary.
A.1.1 Service Initiation A.1.1 Service Initiation
Redirect using tunnels at service initiation requires that the Redirect using tunnels at service initiation requires that the
RADIUS server send the appropriate [RFC2868] tunnel attributes and RADIUS server send the appropriate [RFC2868] tunnel attributes and
NAS-Filter-Rule attributes to the NAS. The [RFC2868] tunnel NAS-Filter-Rule attributes to the NAS. The [RFC2868] tunnel
attributes describe the tunnel endpoint and the type of tunnel to attributes describe the tunnel endpoint and the type of tunnel to
construct. The "tunnel <tunnel_id>" option for the NAS-Filter- construct. The 'tunnel <tunnel_id>' option for the NAS-Filter-
Rule allows the specification of a traffic rule for which to Rule allows the specification of a traffic rule for which to
redirect traffic to a named tunnel. redirect traffic to a named tunnel.
A.1.2 Mid-session Tunnel Redirection A.1.2 Mid-session Tunnel Redirection
Redirection of traffic using tunnels mid-session involves sending Redirection of traffic using tunnels mid-session involves sending
the tunnel attributes as per [RFC2868] to the NAS using Change-of- the tunnel attributes as per [RFC2868] to the NAS using Change-of-
Authorization (CoA) message. The operation is described in Authorization (CoA) message. The operation is described in
[RFC3576]. Careful attention should be paid to the security [RFC3576]. Careful attention should be paid to the security
issues in [RFC3576]. issues in [RFC3576].
skipping to change at page 26, line 49 skipping to change at page 25, line 29
without tunnel attributes would not have an effect on an existing without tunnel attributes would not have an effect on an existing
tunnel. In order to de-tunnel the session, the RADIUS server has tunnel. In order to de-tunnel the session, the RADIUS server has
to send the NAS a CoA message with Service-Type(6) set to to send the NAS a CoA message with Service-Type(6) set to
"Authorize-Only" causing the NAS to perform a re-Authorization. "Authorize-Only" causing the NAS to perform a re-Authorization.
In response to the re-Authorization, the RADIUS server will send In response to the re-Authorization, the RADIUS server will send
an Access-Accept packet without the tunneling information. Upon an Access-Accept packet without the tunneling information. Upon
receiving the corresponding Access-Accept packet the NAS MUST receiving the corresponding Access-Accept packet the NAS MUST
apply the new authorization attributes. If these do not contain apply the new authorization attributes. If these do not contain
tunnel attributes, then the NAS MUST tear down the tunnel. tunnel attributes, then the NAS MUST tear down the tunnel.
A.1.4 Tunnel Redirection Examples
The following examples illustrate how traffic flows when subjected
to a NAS-Filter-Rule using tunnel redirection. In these
scenarios, the following notation is used to represent traffic
flows:
------> Flow in one direction
<-----> Flow in two directions
======> Flow in a tunnel in one direction
<=====> and in both directions
A RADIUS server that wishes all IP traffic to flow between the
client and a selected redirection destination will issue an
Access-Accept that contains the specification for the tunnel using
the attributes defined by RFC 2868 and an NAS-Filter-Rule
attribute using the tunnel action and arguments.
An example NAS-Filter-Rule will look like:
tunnel "t1" in ip from assigned to any
This will cause all traffic that flows from the client to any
destination to be tunneled over the named tunnel "t1" to the
tunnel endpoint (TEP).
+-------+ +------+ +------+ +------+
| | | | |Tunnel| | |
|client +<---------->+ NAS +<==t1===>+ End +<----->+ Dest |
| | | | |Point | | |
+-------+ +------+ +------+ +------+
The direction argument takes the values of "in", "out" or "inout"
and is important because it controls how information is routed.
The following diagram demonstrates how traffic is routed. In all
these diagrams time is increasing as we proceed down the page.
When rule direction is "in":
client NAS TEP DESTINATION
| | | |
|---------->|===t1===>|--------->|
| | | |
|<----------|<-------------------| (flows directly to NAS)
| | | |
The inbound traffic from the client matches the specified filter
rule and the IP packet is placed in the tunnel to the TEP. The TEP
forwards the packet to the Destination using the destination IP
address in the packet header. Note that the source address of the
packet is the address assigned at the NAS. Therefore if the
destination were to reply to the packet it would use the NAS
source address and the packet would flow directly to the NAS and
to the client bypassing the TEP. The Home network would use this
capability if it was only interested in metering or seeing the
inbound traffic from the client.
However, if the home network wanted to see the traffic in both
directions it could deploy a NAT function at the TEP.
Here is the flow when the TEP is acting like a NAT:
client NAS TEP/NAT DESTINATION
| | | |
|---------->|===t1===>|--------->|
| | | |
|<----------|<==t1====|<---------|
The client establishes a connection to the Destination, but the
TEP acting as NAT, changes the source address of the IP packet(as
NATs do) to that of the TEP/NAT. Now any replies from the
Destination are sent to the TEP/NAT. The TEP/NAT then forwards
these packets to the client through the NAS.
When the TEP is acting as a NAT, using the direction argument "in"
is important. The direction argument set to "out" will have no
effect on traffic coming from the tunnel since all traffic to the
client should come from the TEP/NAT inside the tunnel. The
direction argument set to "inout" will have the same effect as if
it were set to "in".
The TEP/NAT forwards all traffic for the client into the tunnel to
the NAS. The NAS always forwards any egressing traffic from the
tunnel to the client. It does not apply any redirection rules on
traffic egressing a tunnel. The NAS does not care whether the TEP
is transparent or is acting as a NAT.
A.2 HTTP Redirection A.2 HTTP Redirection
Another method of redirection is at the application layer, Another method of redirection is at the application layer,
specifically the HTTP layer. An HTTP aware NAS redirects traffic specifically the HTTP layer. An HTTP aware NAS redirects traffic
by issuing an HTTP Redirect response causing the users browser to by issuing an HTTP Redirect response causing the users browser to
navigate to an alternate Web Portal. navigate to an alternate Web Portal.
The call flow associated with performing redirection at the HTTP
layer is very similar with the call flow associated with
redirection done at the IP layer.
The same NAS-Filter-Rule(TBD) attribute described above is used to The same NAS-Filter-Rule(TBD) attribute described above is used to
convey the redirection rules to use for HTTP redirection. HTTP convey the redirection rules to use for HTTP redirection. HTTP
redirection rules within the NAS-Filter-Rule attribute supports redirection rules within the NAS-Filter-Rule attribute supports
the encoding of a redirection URL to apply when a rule is matched. the encoding of a redirection URL to apply when a rule is matched.
A.2.1 Service Initiation A.2.1 Service Initiation
As with previous call flows, the RADIUS MAY send multiple HTTP As with previous call flows, the RADIUS MAY send multiple HTTP
redirect or filtering rules within a NAS-Filter-Rule(TBD) redirect or filtering rules within a NAS-Filter-Rule(TBD)
attribute to the NAS in the Access-Accept message. attribute to the NAS in the Access-Accept message.
skipping to change at page 28, line 40 skipping to change at page 29, line 12
prepaid user is roaming the net in their hotel room over WiFi is prepaid user is roaming the net in their hotel room over WiFi is
to be Hot-lined because their account has no more funds. The to be Hot-lined because their account has no more funds. The
user's Service Provider instructs the NAS to block all traffic, user's Service Provider instructs the NAS to block all traffic,
and redirect any port 80 traffic to the Service Provider's Prepaid and redirect any port 80 traffic to the Service Provider's Prepaid
Portal. Upon detecting that there is no service, the user Portal. Upon detecting that there is no service, the user
launches his browser and regardless of which web site is being launches his browser and regardless of which web site is being
accessed the browser traffic will arrive at the Prepaid Portal accessed the browser traffic will arrive at the Prepaid Portal
which will then return a page back to the subscriber indicating which will then return a page back to the subscriber indicating
that he needs to replenish his account. that he needs to replenish his account.
Appendix B - NAS-Filter-Rule Filter Examples
This appendix presents a variety of filter examples utilizing the
syntax definition described in section 3.5
Example #1: Permit all user traffic, regardless of type.
permit inout any from any to any
Example #2: Permit only L2 traffic coming from and going to a
user's Ethernet MAC address. Block all other traffic. Assume
user's MAC address is 00-10-A4-23-19-C0.
permit in l2:ether2 from 00-10-A4-23-19-C0 to any
permit out l2:ether2 from any to 00-10-A4-23-19-C0
Example #3: Tunnel all L2 traffic coming from and going to a user.
Assume tunnel name is: tunnel "1234".
permit tunnel "tunnel \"1234\"" inout l2:ether2 from any to any
Example #4: Permit only L3 traffic coming and going to from a
user's IP address. Block all other traffic. Assume user's IP
address is 192.0.2.128.
permit in ip from 192.0.2.128 to any
permit out ip from any to 192.0.2.128
Example #5: Permit only L3 traffic coming and going to the user's
assigned IP address. Block all other traffic.
permit in ip from assigned to any
permit out ip from any to assigned
Example #6: Allow user to generate ARP requests, DNS requests, and
HTTP (port 80) requests. Assume user's MAC address is 00-10-A4-23-
19-C0 and IP address is 192.0.2.128.
permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any
permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0
permit in 17 from 192.0.2.168 to any 53
permit out 17 from any 53 to 192.0.2.168
permit in 6 from 192.0.2.168 80 to any
permit out 6 from any 80 to 192.0.2.168
Example #7: Allow user to generate ARP requests, DNS requests, and
HTTP (port 80) requests, any of which are redirected to
http://www.foo.org. Assume user's MAC address is 00-10-A4-23-19-C0
and IP address is 192.0.2.128.
permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any
permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0
permit in 17 from 192.0.2.168 to any 53
permit out 17 from any 53 to 192.0.2.168
redirect http://www.foo.org in from 192.0.2.168 to any 80
Example #8: Allow user to generate ARP requests, DNS requests, and
HTTP (port 80) requests, of which only requests to
http://www.foo.org are redirected to http://www.goo.org. Assume
user's MAC address is 00-10-A4-23-19-C0 and IP address is
192.0.2.128
permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any
permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0
permit in 17 from 192.0.2.168 to any 53
permit out 17 from any 53 to 192.0.2.168
redirect http://www.goo.org in from 192.0.2.168 to any 80
http://www.foo.org
Acknowledgments Acknowledgments
The authors would like to acknowledge Dorothy Stanley of Agere, The authors would like to acknowledge Joseph Salowey of Cisco,
Joseph Salowey of Cisco, David Nelson of Enterasys, Chuck Black David Nelson of Enterasys, Chuck Black of Hewlett Packard, and
of Hewlett Packard, and Ashwin Palekar of Microsoft. Ashwin Palekar of Microsoft.
Authors' Addresses Authors' Addresses
Paul Congdon Paul Congdon
Hewlett Packard Company Hewlett Packard Company
HP ProCurve Networking HP ProCurve Networking
8000 Foothills Blvd, M/S 5662 8000 Foothills Blvd, M/S 5662
Roseville, CA 95747 Roseville, CA 95747
EMail: paul.congdon@hp.com EMail: paul.congdon@hp.com
Phone: +1 916 785 5753 Phone: +1 916 785 5753
Fax: +1 916 785 8478 Fax: +1 916 785 8478
Mauricio Sanchez Mauricio Sanchez
Hewlett Packard Company Hewlett Packard Company
HP ProCurve Networking HP ProCurve Networking
8000 Foothills Blvd, M/S 5559 8000 Foothills Blvd, M/S 5559
Roseville, CA 95747 Roseville, CA 95747
EMail: mauricio.sanchez@hp.com EMail: mauricio.sanchez@hp.com
Phone: +1 916 785 1910 Phone: +1 916 785 1910
Fax: +1 916 785 1815 Fax: +1 916 785 1815
Avi Lior Avi Lior
Bridgewater Systems Corporation Bridgewater Systems Corporation
303 Terry Fox Drive 303 Terry Fox Drive
Suite 100 Suite 100
Ottawa, Ontario K2K 3J1 Ottawa, Ontario K2K 3J1
Canada Canada
skipping to change at page 30, line 10 skipping to change at page 31, line 49
The IETF takes no position regarding the validity or scope of The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the claimed to pertain to the implementation or use of the
technology described in this document or the extent to which technology described in this document or the extent to which
any license under such rights might or might not be available; any license under such rights might or might not be available;
nor does it represent that it has made any independent effort nor does it represent that it has made any independent effort
to identify any such rights. Information on the procedures to identify any such rights. Information on the procedures
with respect to rights in RFC documents can be found in BCP 78 with respect to rights in RFC documents can be found in BCP 78
and BCP 79. and BCP 79.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of assurances of licenses to be made available, or the result of
an attempt made to obtain a general license or permission for an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementers or users of the use of such proprietary rights by implementers or users of
this specification can be obtained from the IETF on-line IPR this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all BCP 78, and except as set forth therein, the authors retain all
their rights. their rights.
 End of changes. 156 change blocks. 
641 lines changed or deleted 747 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/