Issue 41: Pruning the Filter Attribute Thicket

[Bernard Aboba <aboba@internaut.com>]

Issue 41: Pruning the Filter Attribute Thicket
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: December 13, 2004
Reference:
Document: Congdon-02
Comment type: T
Priority: S
Section: 2.7
Rationale/Explanation of issue:
The document currently defines a QoS-Filter-Rule attribute as
well as a NAS-Filter-Rule attribute. RFC 2865 already defines
a Filter-ID attribute which could support any type of filter
(deny/allow, QoS, etc.). We also have draft-lior-radius-redirection
which defines IP-Redirection-Id, IP-Redirection-Rule, HTTP-Redirection-Id
and HTTP-Redirection-Rule attributes.

Creating this many filter-related attributes is asking for trouble,
I think. How are we to merge all these capabilities together if
more than one capability are included in the same Access-Accept
packet? It is hard enough to figure this out just for Filter-Id
and NAS-Filter-Rule.

I think we need to unify these concepts. One potential resolution
is to define a single Filter-Rule syntax that can handle permit/deny,
QoS and redirection filtering at both layer 2 and layer 3.

One question is how the NAS can indicate what level of filtering
it supports assuming that extensions are supported at some point.
My proposal would be to specify the capabilities that we expect
all NAS devices to support in one attribute, then also define
extended attributes that can handle more than one capability.
However, we can then specify that only *one* type of filter
attribute (NAS-Filter-Rule, Extended-NAS-Filter-Rule, etc.) can
appear in a single packet, to simplify the merging problem.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>