RE: [RADIUS FIXES] Authorize Only / RADIUS layering

[<Pasi.Eronen@nokia.com>]

David Nelson wrote:
> 
> So, let me take a moment to address RADIUS layering in a
> pro-active fashion.
> 
> It is certainly appropriate to have layering of one
> application upon the services provided by another.  We need to
> address this general architectural concept within the
> constraints of RADIUS as it exists, and the charter of the
> RADEXT WG.
> 
> RADEXT is not chartered to make major or substantial
> architectural changes to RADIUS.  For example, introducing
> layering akin to the base / application layering in Diameter
> is certainly out of scope.
> 
> It would, generally speaking, be appropriate for RADEXT to
> consider standardization of new attributes for the
> provisioning of existing, well-defined services that exist on
> the NAS.  Traditionally, these attributes have used the data
> types defined in RFC 2865 and have been transparent to the
> RADIUS protocol engines, in both clients and servers.  The
> vast majority of existing RADIUS attributes is acted upon by
> application layer software outside the scope of the RADIUS
> protocol engine, and its associated support and management
> components. So layering does already exist, to this extent.

This is an interesting and pretty accurate observation. Current
RADIUS documents are mostly concerned with how attributes are
transported from one place to another (and how multiple
attribute packed to a single message are separated). How the
attributes are acted upon (what they mean, or what their
semantics are) is largely unspecified in IETF RADIUS documents.

> The specific practice that I'm suggesting is undesirable is
> the definition of new RADIUS attributes, and their basic
> semantic descriptions, in RFCs defining the applications,
> rather than in [companion] RADIUS extensions RFCs.  That does
> not mean that the I-Ds for such RADIUS extensions need to be
> work items for the RADEXT WG.  They could be work items for
> other IETF WGs (or conceptually even other SDOs), with
> concurrent review and WG Last Calls in RADEXT and the other
> WG(s).  In any event, the collection of IETF standard
> attributes (anything other than VSAs) should be treated as a
> consistent body of work, and be considered as elements of the
> RADIUS protocol.
> 
> RADIUS does not have a formal language that would allow the
> independent publication of data objects, much as we have MIBs
> for SNMP and PIBs for COPS.

This is where I disagree to some extent. I think the current
practice of defining only the syntax of RADIUS attributes, but
not the semantics, is very undesirable. One possible way to
avoid this is to define the syntax and the semantics in the 
same document...

And IMHO we don't need a formal language, since all it could
do is describing the syntactic parts (e.g., this attribute can
be included only in Access-Accept messages, and contains a
32-bit integer). I don't currently see big problems in this 
area; the problem is that documentation doesn't describe
how the attributes are acted upon.

If we are concerned with interoperability of whole RADIUS
clients and servers, rather than just "RADIUS protocol engines",
the endpoints need to agree on those semantics, too. Currently
that is pretty much left to implementation folklore (in the
worst case) or documents by other SDOs (in the best case).

I think Avi's example of using "Authorize Only" for replenishing
prepaid quota is a good example of this. The syntax of the
attributes is defined in IETF specs, but actual interoperability
requires some agreement of how the messages are acted upon that
not's specified in any IETF document. (I'm not sure if it's
specified in any document, in fact...)

Best regards,
Pasi

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