Re: Request for Review: RADIUS Filter Attribute Document

[Barney Wolff <barney@databus.com>]

On Tue, Oct 17, 2006 at 07:01:57PM -0700, Bernard Aboba wrote:
> The RADIUS Filter Attribute document has gone through another revision to 
> address the filter continuation issue.  Please review the current version 
> and send comments to the WG list:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt
> 
> Are the changes an improvement?

I am increasingly convinced that the attempt to re-use the tag mechanism
for segmentation and concatenation is misguided and will lead implementers
into trouble.  In the realm of biology, frequent instances of genes and
structures being re-used, often quite clumsily, for completely new
functions is one of the proofs of natural evolution rather than intelligent
design.  But protocols do, or should, have intelligent designers.

Tags were designed to collect different attributes, in arbitrary order,
into groups.  Limitations on tag values (originally 0x01-0x1f - when did
that change to 0x3f?) were motivated by allowing the tags to be optional.
Group precedence was defined by an explicit attribute.

For segmentation, a simple 1-bit question needs to be answered:  Does
this attribute, of maximum length, stand on its own or is the next
filter attribute to be concatenated with it?  From that point of view,
the rules on tag values and especially against repetition of a tag
value, make no sense.

But there is a more subtle trap waiting for the implementer who blindly
uses existing tag code.  Filter rule precedence is governed by
the order of appearance in the RADIUS message.  Within a given tag
value, the code may well just happen to work that way.  But across
different tag values it most likely will not.  Thus all the attributes
with tag '0' will maintain order, but any rule that needs segmentation
will lose its position information relative to all others.  Since huge
rules are actually quite rare, I suspect such bugs will survive to be
fielded.

I propose, instead, that Avi's suggestion of reserving one bit of the
tag field for segmentation and leaving the other 7 for grouping be
adopted, and that the bit be called MORE, indicating that this
attribute is not the last piece of the rule.  (One could just as
well name it EXT and have it set only in the attribute that extends
the previous one.  There are pros and cons either way.)

-- 
Barney Wolff         I never met a computer I didn't like.

--
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/>