[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RADIUS and complex attributes
For some of the mechanisms that we need to support, we are going to have
complex attributes with internal structure. A good example is
prepaid. Given the complexities in prepaid, and the relationships among
the information, flattening the full set of information into top level
RADIUS attributes makes very little sense.
So what are the alternatives for problems that need to be carried in
RADIUS, and require complex information. I have seen the following suggested:
Flatten the attributes, use "tags" to tie the together. While this works
for some simple cases, it gets pretty hairy pretty quickly.
Let folks use VSAs. One participant indicated that he did not see vendors
saying that they would move from VSAs to standard attributes. For many
environments, there are very good reasons to prefer and move to
standards. The fact that we have to work with each RADIUS server vendor
individually at each customer to get support for the VSAs we need for
prepaid is NOT an advantage. It would be worth the small amount of work to
switch to switch our client to use standard attributes. And I presume that
the RADIUS server vendors would much prefer not to need a different
implementation for each client that they have to work with. Sticking with
VSAs for widely need features is simply a mistake.
Allow complex attributes. Call them subtypes if you like (or dislike) the
point is that the information to be carried has internal structure and
meaning. It is very helpful if this structure can be standardized and
described. It seems highly desirable to do that at the IETF rather than
separately at IEEE, 3GPP, 3GPP2, the DSL Forum, ... And if we are going to
do it at the IETF, this working group seems the right place to do this.
In trying to follow the argument against complex attribute values, it seems
that the argument is that such things should not be allowed within RADIUS,
but only when they are a "carried application". It is understandable (and
I support) that such attributes should not be mandatory for all clients or
all servers, and that in general relays that are not adding value in the
space of the complex attribute should be able to treat the attribute as a
string.
Once that much is said, the discussion seems to devolve into an assertion
that if it is a carried application than it must be some other working
group, and that the RADIUSEXT working group should not be defining such
applications. Given that each of the applications is relatively small, and
that unfortunately working groups carry a lot of overhead, it would simply
seem more practical to define the extensions in the RADIUSEXT working group
rather than trying to define a "prepaid" services WG and a "bandwidth
allowance" working group, and...
Yours,
Joel M. Halpern
--
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/>