[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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