RE: FW: HTTP digest and RADIUS; new version of the Sterman draft

[Avi Lior <avi@bridgewatersystems.com>]

Thank you for the reply.  Here is my follow up.

Can you show me in either sterman or lior where we are adding a new type to
RADIUS?

The encoding used for the string attributes may be functinally equivalent to
a Grouped attribute but its not the same because we are not seeking to
create a new attribute. If we were creating a grouped type then code would
have to change because RADIUS dictionaries know about string and don't know
about Grouped AVPs.

So specifically, sterman/lior do not break RADIUS dictionaries. Right?

Passing this attributes over a proxy chain today will not create a problem
right?  No new code would have to be introduced to handle these attributes.

I wish to debate the pros and cons of introducing an Grouped AVPs but I
don't want that debate to get in the way of the specific case. (At least in
this email).


> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: February 14, 2004 12:19 PM
> To: Avi Lior
> Cc: Alan DeKok; radiusext@ops.ietf.org
> Subject: RE: FW: HTTP digest and RADIUS; new version of the 
> Sterman draft 
> 
> 
> > While this debate is interesting its not addressing the 
> issue. We are 
> > not trying to create a new fundemental type!  We agree That 
> this would 
> > break RADIUS.
> >
> > Sterman draft and my prepaid draft are not introducing any new 
> > fundemental type. We are introducing a new Attribute of Type String.
> >
> > Given that, that this is only to be decoded at the RADIUS 
> server for 
> > which the Attribute is intended (and not by proxies) then how does 
> > this break existing RADIUS Server?
> 
> This is the equivalent to Diameter's Grouped AVPs.  Note that 
> grouping is allowed within RFC 2865 only for attributes of 
> Type 26 (Vendor Specific).  In Section 5.26, it states:
> 
> "     Multiple subattributes MAY be encoded within a single Vendor-
>       Specific attribute, although they do not have to be."
> 
> Grouped AVPs do not violate the fundamental design principle 
> of Diameter, since a Diameter server is assumed to be able to 
> handle the addition of a Grouped AVP without code changes.
> 
> However, some constraints are required to limit the resulting 
> complexity. Diameter Grouped AVPs prohibit nesting within 
> sub-types (e.g. no Grouped AVP within a Grouped AVP), and 
> permit sub-AVPs only to utilize one of the Types defined in Diameter.
> 
> That said, there are some additional constraints that appear 
> in RADIUS.
> 
> a. Efficiency.  The "tagged" approach taken in RFC 2867 and 
> 2868 is more efficient than Grouped AVPs, and therefore is 
> probably to be preferred, everything else being equal.  Do we 
> have examples where the "tagged" approach would not work?
> 
> b. Length constraints.  Unlike Diameter, RADIUS attributes 
> can only be 253 octets in length.  If Grouped AVPs are in 
> aggregate longer than this, then it will be necessary to 
> support fragmentation and reassembly of Grouped AVPs which 
> increases complexity.
> 

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