RE: Extending RADIUS Attribute Space

[Avi Lior <avi@bridgewatersystems.com>]

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Friday, August 22, 2003 12:44 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Extending RADIUS Attribute Space
> 
> 
> 
> Avi Lior writes...
> 
> > If we want to interoperate with Diameter for example, how would we
> address
> > the fact that the length of a diameter attribute is 3 octets?
> > 
> > Is this enough of a justification to allow RADIUS Extended 
> attributes
> to
> > be longer than 1 octet in length?
> 
> Well, I don't know.  I think it once again depends on the 
> actual attributes and applications under consideration.  If 
> RADIUS has a well-defined mechanism for achieving 
> application-level fragmentation and re-assembly of "oversize" 
> attributes, why isn't it sufficient for a RADIUS-Diameter 
> gateway function to utilize that fragmentation and 
> re-assembly when translating between RADIUS and Diameter? 

RADIUS does not have a scheme for doing this. So EAP has a mechanism for
dealing with big attributes but it would be wrong to use EAP messages to
implement something like prepaid or any other application that is not an EAP
application.

I don't think it would be a good idea to create a situation where every
RADIUS application RFC comes up with its own way of dealing with big
attributes.

 
> Making the translation simple and straightforward is 
> important, but I think that requirement can be met with 
> fragmentation and re-assembly.  

I don't understand what you mean here.  If you meant "requirment can be met
with frametation and re-assembly that exists in RADIUS" then I have answered
above.

>Execution efficiency is another matter, of course...
> 
> -- 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/>