[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments from the editor of RFC 4005 on Filter-Id & NAS-Filter-Rule (fwd)
RFC 4005 recommends that the NAS-Filter-Rule AVP be used instead of the
Filter-Id AVP, but does not require this. Below, David Mitton, editor of
RFC 4005, comments on the thinking behind the RFC 4005 text.
-----------------------------------------------
Date: Tue, 21 Nov 2006 10:04:46 -0500
From: David Mitton <david@mitton.com>
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: Inclusion of Filter-Id and NAS-Filter-Rule AVPs
I'm not sure I have much enlightenment to spread here, but I
might have a clue on the orginal motivation.
Comments embedded below....
Dave.
RFC 4005 Section 6.7 states the following with respect to the Filter-Id
AVP:
In non-RADIUS environments, it is RECOMMENDED that the NAS-Filter-
Rule AVP be used instead.
However, since this is a recommendation, it appears possible that an RFC
4005 implementation could send a NAS-Filter-Rule AVP along with a
Filter-Id AVP. Based on the current text in the NAS-Filter-Rule document,
such a message would not be translatable to an equivalent RADIUS packet.
At the time of RFC 4005 authoring, the NAS-Filter-Rule AVP was not
expressable as a RADIUS attribute, as it has the Diameter AVP code of 400.
So I doubt that combining the two was intended. Given the current lack of
enthusiasm for mapping Diameter into RADIUS, that still may be the case.
Some questions:
a. Do you, the esteemed author of RFC 4005 have an opinion on the
appropriate normative language for the Section 2 text above? For
example, is the "MUST NOT" too strict?
I think it depends on the next issue. If this technique is now officially
frowned on, then it's probably not too strict.
b. Is there a situation in which both the NAS-Filter-Rule and Filter-Id
AVPs will need to be sent in a >Diameter message?
I suspect that we (some?) believed that some servers might send both, and if
the message was headed to an older system, a gateway would strip the
NAS-Filter-Rule but take the Filter-ID. Of course this supposes that the
Diameter system would have a defined behavior for both the Filter-ID and
Filter-Rule.
c. If such a situation exists, how is a NAS to interpret such a message?
Does one AVP take precedence? Or are the AVPs combined somehow?
This is an area where there is a total lack of vendor standardization. The
Xylogics Annex had a filtering command system unlike anything Cisco, Ascend,
or 3Com had at the time.
Rules typically have some sort of sequential processing assumptions, and to
try to combine a predefined set (the Filter-ID definition) with another set
(the Filter-Rules) it could be problematic.
But the implementor of the new standard rules would have to deal with the
native interface somewhere during implementation anyways.
So I think any assumption of combining both was not an expectation.
However, this problem could be left to the system operator given his
configuration & equipment capabilities to decide. So, that may be why there
is a lack of totally restrictive language.
I think the original intent was to define a new common Filter-Rule for
Diameter native systems (something we have not had in the past), while
accommodating RADIUS standard attributes and practice. Diameter systems
must define how they want to interpret this situation, since it is clearly
allowed. It this attribute is also to be implemented in the RADIUS space,
then they have the same problem.
Sigh... this is another problem where some sort of NAS version number or
capabilities field would be useful. I guess the best compromise would be to
continue to allow them to be sent together.
An older system would ignore the new rule and use the Filter-ID. A newer
system would use the new rules (if present) and either ignore the Filter-ID
or have it defined as a Non-operation. The provisioning of the rules behind
a Filter-ID are still not defined.
Dave
--
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/>