Subject: RE: [AAA-WG]: Extension requirements?

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 3 Mar 2001 06:43:37 -0800

>given the liklihood of vendor-specific (and even implementation-specific)
>extensions

I understand the need for vendor-specific *attributes*, but vendor-specific
extensions?

One of the fundamental architectural principles of AAA is that
new attributes should not require any new code on the AAA server, only
a new  dictionary entry. This is fundamental to the AAA architecture,
because it provides the flexibility necessary to add new attributes
to the protocol without having to upgrade servers. This works because
typically only the NAS needs to understand the semantics of a given
attribute. The major exception to this model are the authentication
attributes (User-Password, CHAP-Password, EAP-Message, etc.) which
require code to exist on the AAA server in order to verify them.

>But many RADIUS servers are home-grown, part of closed systems.  If history
>is a guide, many Diameter servers will be, too.  So why would the
developers
>thereof care about the market?  Why should they be required to implement
>something they will never use, just to be conformant?

If we are adhering to the fundamental principles of AAA architecture, the
answer to that question would be "because supporting additional attributes
doesn't impose any additional work, other than new dictionary entries".
The major exception to this would be attributes relating to authentication,
which do require new code.

If the work involved in implementing new attributes is significantly
greater than this, then this results in a significant loss in
flexibility. This would be the equivalent of treating SNMP MIBs
as "extensions" and assuming that it would be impossible to suport them
on an SNMP manager without code changes to the manager.