RADIUS Filter Rule Attribute
RFC 4849
Network Working Group P. Congdon
Request for Comments: 4849 M. Sanchez
Category: Standards Track ProCurve Networking by HP
B. Aboba
Microsoft Corporation
April 2007
RADIUS Filter Rule Attribute
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
While RFC 2865 defines the Filter-Id attribute, it requires that the
Network Access Server (NAS) be pre-populated with the desired
filters. However, in situations where the server operator does not
know which filters have been pre-populated, it is useful to specify
filter rules explicitly. This document defines the NAS-Filter-Rule
attribute within the Remote Authentication Dial In User Service
(RADIUS). This attribute is based on the Diameter NAS-Filter-Rule
Attribute Value Pair (AVP) described in RFC 4005, and the
IPFilterRule syntax defined in RFC 3588.
Congdon, et al. Standards Track [Page 1]
RFC 4849 Filter Rule Attribute April 2007
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Requirements Language ......................................3
1.3. Attribute Interpretation ...................................3
2. NAS-Filter-Rule Attribute .......................................3
3. Table of Attributes .............................................5
4. Diameter Considerations .........................................5
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
8. Acknowledgments .................................................7
1. Introduction
This document defines the NAS-Filter-Rule attribute within the Remote
Authentication Dial In User Service (RADIUS). This attribute has the
same functionality as the Diameter NAS-Filter-Rule AVP (400) defined
in [RFC4005], Section 6.6, and the same syntax as an IPFilterRule
defined in [RFC3588], Section 4.3. This attribute may prove useful
for provisioning of filter rules.
While [RFC2865], Section 5.11, defines the Filter-Id attribute (11),
it requires that the Network Access Server (NAS) be pre-populated
with the desired filters. However, in situations where the server
operator does not know which filters have been pre-populated, it is
useful to specify filter rules explicitly.
1.1. Terminology
This document uses the following terms:
Network Access Server (NAS)
A device that provides an access service for a user to a network.
RADIUS server
A RADIUS authentication server is an entity that provides an
authentication service to a NAS.
RADIUS proxy
A RADIUS proxy acts as an authentication server to the NAS, and a
RADIUS client to the RADIUS server.
Congdon, et al. Standards Track [Page 2]
RFC 4849 Filter Rule Attribute April 2007
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. Attribute Interpretation
If a NAS conforming to this specification receives an Access-Accept
packet containing a NAS-Filter-Rule attribute that it cannot apply,
it MUST act as though it had received an Access-Reject. [RFC3576]
requires that a NAS receiving a Change of Authorization Request
(CoA-Request) reply with a CoA-NAK if the Request contains an
unsupported attribute. It is RECOMMENDED that an Error-Cause
attribute with value set to "Unsupported Attribute" (401) be included
in the CoA-NAK. As noted in [RFC3576], authorization changes are
atomic so that this situation does not result in session termination,
and the pre-existing configuration remains unchanged. As a result,
no accounting packets should be generated because of the CoA-Request.
Show full document text