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

["Alan DeKok" <aland@ox.org>]

"Nelson, David" <dnelson@enterasys.com> wrote:
> The technical arguments that I have heard (and advanced) against
> sub-types are that it changes the RADIUS architecture (simple TLV
> structures), requires changes to the RADIUS dictionary, and breaks
> backwards compatibility with a large deployed base of RADIUS products.

  ... which we already know won't understand the new attributes.

  The only hard requirement I can see for backwards compatibility is
that old servers MUST be able to act as proxies for requests with new
attributes.  We've seen this behaviour with EAP-Message, so we know it
works.

> With SNMP, MIBs can be enrolled in SNMP management stations by a
> mechanical process because you can't re-define the ASN.1/BER data
> formats used in SNMP.  Should we settle for any less in RADIUS?

  No, but RADIUS does more.  The vast majority of use of SNMP is for
monitoring.  The SNMP servers don't *do* anything with the data they
manage.  That is, we generally don't expect to do an SNMP write in one
place, and then read back data elsewhere which is calculated by some
algorithm from the updates.  If that does happen, that data is usually
calculated by something outside of SNMP, like another application.

  RADIUS is an "active" protocol, in that it changes its responses
based on different inputs.  In contrast, SNMP is much more "passive".
This difference means that analogies to SNMP are less than perfect.

> However the sub-type attributes are not in any fundamental way different
> from "normal" RADIUS attributes.  So what are the reasons offered for
> treating them differently?  One reason seems to be "the convenience of
> grouping".  RADIUS already has a recognized method of grouping
> attributes.

  Using tunnel-type "tags" for grouping attributes is reasonable.

> A second reason seems to be "we will run out of attribute
> number space".  Let's take a head count of new attributes that fall
> within the scope of the charter before we deiced that, shall we?

  The rouch count posted to the list was what, 40-80 attributes?
That's at least approaching the boundary.

> While I do find the backwards compatibility reasons for NOT allowing
> sub-types to be compelling, I don't find the two reasons I have listed
> for allowing them to be compelling.

  If tagged attributes are sufficient, then I see no reason to add new
sub-types.

  Alan DeKok.

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