[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Review: RADIUS Filter Attribute Document
Hi,
On Wed, Oct 18, 2006 at 09:45:49PM -0700, Bernard Aboba wrote:
> >I have mixed feelings. On the one hand, there is precedent for glomming
> >all instances of an attribute together, for EAP. On the other, EAP is
> >different in that the RADIUS code does not parse the result. What will
> >happen with the next attribute, where a byte value of 0x00 may be valid?
>
> This approach works for this particular attribute because the IPFilter
> syntax only permits ASCII characters. It's not a general solution, as you
> point out. That wider problem may be part of the extended attribute
> discussion. Since NAS-Filter-Rule isn't an extended attribute I think that
> discussion is somewhat orthogonal.
Well, the solution may be more general than people think, considering it
has two orthogonal parts: 1. concatenation, 2. splitting.
The first part, concatenation, can be used
a. stand-alone (without subsequent splitting), useful for eg. EAP, but
also for all other > 253 attributes of which only 0..1 instances can
occur;
b. with splitting on a delimiter (as just proposed for NAS-Filter-Rule);
c. with splitting based on a length, value scheme (needed for octet string
attributes), and
d. with splitting based on a type, (flags or tag + child tag), length,
value scheme, as proposed in the various extended attribute drafts.
If you can't put any constraints on the values of the octets in an
attribute, then you simply need c. instead of b., but the method of
concatenation while disregarding original attribute boundaries still
stands.
How does c. work? Let's assume we need a new (octet) string attribute,
0..n instances, any number of instances, possibly > 253 in length.
As said, we first perform standard attribute concatenation, to get a
single octet string of size up to ~4000.
Then, instead of splitting on a delimiter as proposed for
NAS-Filter-Rule, you decode this string as a series of length, value
pairs to get the real "instances":
0 1 2
+----+----+----+---- ~ --+----+----+----+----
| Length1 | Value1... | Length2 | Value2...
+----+----+----+---- ~ --+----+----+----+----
If that looks familiar, it is; it's a normal RADIUS attribute without
the 'type' field and with a 2-octet length field.
So, it's pick and choose. We don't even need to design a single extended
attribute that does it all.
You can overcome the <= 253 value size limit by concatenation, at the
price of limiting an attribute to one long instance. This is sufficient
for EAP-Message and possibly other attributes.
On top of that facility, you can overcome the single long instance limit
per attribute type by splitting on delimiters, at the price of limiting
value ranges (sufficient for NAS-Filter-Rule), or by splitting using
internal length fields.
On top of the last facility, you can overcome the <= 255 attribute type
number space limit by adding a (wider) type field to each internal
attribute instance contained in the concatenated string.
To overcome the limited outer structure (flat list of attributes), you
can either physically nest attributes inside one another (diameter-based
drafts), or add a tag and a child-tag field (my draft) to each internal
attribute instance contained in the concatenated string.
In short, the concatenation half of the solution is as generic as you
can get; it's already in use for EAP and you can build all other
facilities that were discussed here in the past year on top of it.
The splitting-on-a-delimiter is indeed limited to text values, but we
can just as well decide to split-on-a-two-octet-length-field instead,
which has no other side effects than being slightly less efficient for
text values.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)78 6136282 http://www.e-advies.nl
--
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/>