RADIUS Design Guidelines

["Nelson, David" <dnelson@enterasys.com>]

I've been giving some thought to the current RADIUS Design Guidelines
draft, and the group consensus regarding that document and the Extended
Attribute, coming out of IETF-66.

The currently evolving proposals for Extended Attributes, solve some of
the issues that have been identified in the Design Guidelines draft:
shortage of attribute IDs, grouping of attributes, and an explicit
method of fragmentation and reassembly.

The one remaining issue raised in the RADIUS Design Guidelines draft not
addressed is the issue of multi-part data values.  Most of the RADIUS
work to date has simply addressed this by defining an attribute, of
base-type String, and then defining sub-fields within the string.

There is nothing inherently wrong with this approach, except perhaps
that it makes it more difficult to maintain data dictionary driven
implementations.

I have a suggestion to float, in term of the BCP for attribute design.
I'd like to suggest that any value portion of a RADIUS TLV that has
multiple parts be formally defined in the document as a SEQUENCE of
pre-defined RADIUS base-types.  I'm stealing the SMI syntax for
SEQUENCE, as used in creating conceptual tables for MIB modules.  It
would be relatively easy for data dictionary driven implementations to
automatically understand a sequence of pre-defined base types.

Let me provide a contrived example.  Suppose we want to define a new
attribute whose value is a complex number.  For those who may have
forgotten, a complex number consists of a real part and an imaginary
part.  This is most often represented as: n + m*i, where n and m are
real numbers and i is the square root of -1.  Such a hypothetical
attribute light look like:

<example>

Complex-Number

   Description

   A complex number, consisting to two parts, a real part N and an 
   imaginary part M, such that the value is N + M*i, where i is the
   square root of -1.

   A summary of the Complex Number Attribute format is shown below.
   The fields are transmitted from left to right.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Real-Part (N)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Real-Part (cont)         |          Imaginary-Part (M)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Imaginary-Part (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBA for Complex-Number.

   Length

      10

   Value

      SEQUENCE OF Real-Part, Imaginary-Part

   Real-Part

      RADIUS base-type of Integer.  The real part of the complex number.

   Imaginary-Part

      RADIUS base-type of Integer.  The imaginary part of the complex
      number.

</example>

I think there is some value here in the ability for data dictionary
driven implementations to easily accommodate multi-part value fields
that are simple concatenations, or sequences, of pre-defined base data
types.

A counter example would be an attribute with varying length fields, some
maybe only one or two octets in length.  These types of constructs
require custom parsing code.

The one additional caveat, that comes to mind, is that variable length
fields would need to (a) only occur at the end of all fixed length
fields, (b) have an explicit length field, or (c) have an explicit
delimiter field.

Comments on this line of thought?



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