RE: Extending a RADIUS attribute (was subtypes....)

[Avi Lior <avi@bridgewatersystems.com>]

David,

So I agree that perhaps the unreliable was not the correct word to use (as
you suggest). But nevertheless it has problems.

If I actually need to have multiple values of the attribute then simply
repeating the attribute  is not workable.  It would be difficult if not
impossible for the RADIUS server to tell whether the next attribute is a
continuation of the previous one or a new one.

Strangely someone asked me just this question about my redirection draft.

There the REDIRECTION rule can get lengthy and I need to be able to send
more than one.  Therefore I replied as follows:
 
I can extend the content of the REDIRECT-RULE attribute over back to back
attributes.  But this method is not good if we want more then one REDIRECT
attribute and we do.
 
Therefore the correct way to do this is to include the length of the overall
data and then split it over back-to-back attributes.  Another method is to
reserve a key word such as "more".  If "more" is found at the end of the
first chunk then the next attribute is an extension of the first.  Both
method s would work in my case because the value type of the attribute is
TEXT.

But this does highlight the fact that there is no standard way to extend
attributes in RADIUS that works across the board.  Hence my discussion many
moons ago about extending attributes.



> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Monday, February 16, 2004 4:36 PM
> To: Avi Lior; radiusext@ops.ietf.org
> Subject: RE: subtypes (was: HTTP digest and RADIUS; new 
> version of the Stermandraft)
> 
> 
> Avi Lior writes...
> 
> > Today if I have a string attribute that is longer than 253 octets
> > -- I could extend it by putting the contents in back-to-back
> > attributes.  This however is not a very reliable way of extending 
> > an attribute.
> 
> My understanding, from the context of early RADIUS WG 
> discussions, is that this is exactly what is intended.  The 
> RFCs are less that crystal clear on this issue, however.  The 
> only RADIUS attributes that have ordering requirements (e.g. 
> in proxy handling) are those string types that can contain a 
> continuation of a string value from one attribute to another. 
>  The requirement to preserve order makes the re-assembly possible.
> 
> As to reliability, I see no reason that this method is any 
> more unreliable than the underlying RADIUS transport 
> mechanism.  It may be slightly cumbersome, but I would not 
> characterize it as unreliable.
> 
> -- 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/>