RE: Question regarding draft-ietf-radext-design-05.txt

["Dave Nelson" <d.b.nelson@comcast.net>]

Hannes Tschofenig writes...

> To give you an example: Some time back when RFC 4675 was written it was
> state-of-the-art to define an attribute as:
>
> User-Priority-Table
>
>       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       |          String
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    String
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    String            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>
>
> Where 'String' represented a customing encoding.

OK, let's examine this case a bit further.  The string value is composed as
follows:

      The String field is 8 octets in length and includes a table that
      maps the incoming priority (if it is set -- the default is 0) into
      one of eight regenerated priorities.  The first octet maps to
      incoming priority 0, the second octet to incoming priority 1, etc.

That is to say, it is an octet array -- a singly dimensioned array of
one-octet values.  That seems to me to be the very definition of the base
RADIUS data type "String".  I see no issue here.

> Today, the encoding of RFC 4675 might quite likely be different and 
> there is still a lot of possibility to argue around why this is still
> a good encoding.

I think you need to use a more complex example to illustrate your point.  An
octet array is a base data type.  To stretch the capabilities of "classic"
RADIUS, you need to attempt to encode the equivalent of C-language
structures, arrays of structures, structures of arrays, or structures of
structures.

> Whether the AAA server had to be updated in order to provide additional
> parsing capability depends a lot on the procedure how some of these
> attributes (and the values in them) get introduced into the system in
> the first place.

Well, that sounds like a user interface discussion, and thus out of scope
for RADIUS attribute design.  In the example you have given, the
User-Priority-Table can be treated by the AAA server as a fixed length
string of 8 octets.  Parsing may be required to enter the values into the
local database, but it's not required during authentication request
processing.

> In some systems they might be statically provisioned into a
> database and just retrieved without any additional logic...

Right.

>... and in other systems they would be dynamically generated and there
> might be some logic behind all this stuff. 

Perhaps.  What you are suggesting is that the user interface (UI) of the AAA
server might be replaced or supplemented by an application programming
interface (API).  Sure.  But that doesn't make the needs of the API a matter
of concern for the RADIUS on-the-wire message format.  That's all we
typically standardize, right?  The on-the-wire message format.

I think we need to apply a little judicious software architecture here.
While all sorts of auxiliary policy engines, data base interfaces, proxy
mechanisms, and other added value applications might be utilized by an AAA
server in "fetching" the values to populate attributes (AVPs), that doesn't
mean that those elements are part of the AAA server.  They may be packaged
as one deliverable for engineering or marketing reasons, but architecturally
they are logically separate entities.  If we always attempted to accommodate
complex systems, composed of multiple cooperating components, every time we
designed any component-level on-the-wire protocol in the IETF, we'd never
get anything accomplished.  I think it's a mistake to attempt to do that
here.

Now, there are other reasons that developers want to use complex attributes,
which don't hinge on system integration issues.  There are data objects that
a server may want to provision in a NAS that are inherently multi-part.  One
classic example is cryptographic keys, which often have a cipher-suite name,
a key name, a lifetime, and a scope that need to be attached to each key.
In that example there is no way to get around the need for structured data.
The question is how to achieve the structuring.

Is the existing tagging mechanism of the Extend Attribute draft sufficient?
I think the answer is yes, unless you want to have multiple keys that are
somehow associated with other attributes in the message (which would require
two distinct tag fields).  The question the RADEXT WG has tried to grapple
with is how complicated do we need to get?  What's the simplest attribute
encoding design that covers 80% of the likely use cases?  I, for one, am
willing to relegate the remaining 20% of use cases to Diameter-only
solutions. :-)  YMMV.

> Still, there is this tendency to label custom encoding (like the one
> from above) as really bad (by calling it "interoperability and deployment
> issues" or see the discussion in Section 2.1.4 of draft-ietf-radext-
> design-05.txt regarding "Complex Attributes and Security").

IMHO, the reason that these encodings are "bad" is two fold: (1) they do not
support the needs of data dictionary driven server implementations, and (2)
the technique for encoding them is ad-hoc (based on the personal design
choices of developers), which precludes any single set enhancements to data
dictionary driven server implementations which might allow them to deal with
a broad class of such attributes.



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