Re: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]

[Alan DeKok <aland@deployingradius.com>]

>>      * it is easier for the user to enter the data as well-known
>>        types, rather than complex structures;
>>
>> I believe this text shouldn't really say "user". Even on the AAA server
>> (to which this text is most likely pointing to)
>> I think it is worth pointing out that this depends a lot on where the
>> data comes from; often it does not come from a human.

  Sure.  That could say:

  * it is easier for the data to be managed as well-known types...

>>      * it enables additional error checking by leveraging the
>>        parsing and validation routines for well-known types;
>>
>> If you are truely serious about this issue then one should replicate the
>> Diameter mechanisms where you can group AVPs arbitrarily and where you
>> have far more data types available.

  Nice idea, but this is RADIUS.  We can't change it at this point.

>> I would like to discuss this statement a bit. It makes an assumption
>> about the way how a RADIUS server works that might not be
>> how it is always being used today. It indicates that a RADIUS server
>> works roughly in the following way:
>>
>> a) Receive attributes (e.g., attribute foobar)
>> b) Formulate a query based on the received attributes (e.g., select
>> foobar from tables where user-id=X)
>> c) Return result from previous query

  No.  It assumes that policies inside of the RADIUS server are managed
by attribute *name*, rather than on-the-wire number.

>> This ignores that there might be more complex processing going on in the
>> RADIUS server, for example that other protocols
>> need to get invoked to get the result (e.g., attributes Y require LDAP
>> to fetch results from server X while other mechanisms may be consulted
>> to obtain the necessary information related to attributes Z),
>> that there is some business logic that needs to be executed).

  That happens, but it's independent of RADIUS dictionaries.

>> I would at least like to relax this statement a bit and acknowledge the
>> fact that RADIUS servers are a bit more complex today than
>> just boxes where one could have used SQL instead of the RADIUS protocol
>> right away.

  The original servers didn't even use SQL...

>> I think that policy languages in AAA servers are getting more common
>> today.
>> During the Diameter interop I have seen a lot of vendors using quite
>> sophisticated policy languages and their boxes supported (in almost all
>> cases) not only Diameter but also RADIUS (and other protocols).

  Yes.  Some RADIUS servers also support complex attribute decoding
through simple scripting languages.  But this has not been historically
wide-spread.

>> Finally, I would like to mention that RADIUS documents sometimes specify
>> RADIUS/Diameter compatibility in a wrong fashion.

  Are there any changes required to the design guidelines document?  Can
you offer suggested text?

>> The following paragraph (and a lot of related text) is related to the
>> aspect of policy languages:
>>
>>   However, some standard attributes do not follow this format.
>>   Attributes that use sub-fields instead of using a basic data type are
>>   known as "complex attributes".  As described below, the definition of
>>   complex attributes can lead to interoperability and deployment
>>   issues, so they need to be introduced with care.
>>
>> It somewhat depends on how the policy language works and what you expect
>> the policy language todo.

 "Can lead ...".  The text is describing common practices and
deployments.  The only reason to change the text is if those practices
are not, in fact, in common use.

>> If you also assume that the policy language is not only used to deal
>> with the business logic but also with decoding and encoding of attribute
>> content then one could deal with a number of interoperability and
>> security issues with the choice of language.

  This is really splitting hairs over what "code" is.  Assembler is
code.  Policy languages are (not?) code.  Java is intermediate...

  In any case, *some* logic has to be updated for complex attributes.

>> Btw, has the draft been sent to other SDOs for review?

  Suggestions?

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