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

["Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>]

Hi David, 

>Hannes Tschofenig writes...
>
>>> The issue is whether extensions to the RADIUS on-the-wire protocol 
>>> should be designed to accommodate the traditional, 
>>> data-dictionary-driven RADIUS server, or not.  I think what we are 
>>> saying is that, while complex RADIUS server implementations exist, 
>>> RADIUS protocol enhancements should not be at the expense of the 
>>> simple implementations.
>> 
>> I think it is not a question of simple or complex implementation.
>> The main issue is what the specific customers want. AAA servers are 
>> used by different clusters of customers (different types of 
>> enterprises, WLAN hotspots, universities, ISPs, cellular operators, 
>> etc). These customers have different needs but the guidelines do not 
>> acknowledge that there are different classes of customers and hence 
>> the design guidelines are often applied without considering 
>these aspects.
>
>Certainly there are different classes of customers, different 
>market segments, different use cases, etc.  Does that mean 
>that the protocol has to differ to address each?

No. I am asking for considering the needs of some of the other usage
environments as well. 

>IMHO, that's 
>not a formal "protocol" if it differs depending on who's using 
>it.  The syntax, i.e. message format, of a protocol needs to 
>be invariant; only the content of the messages should be variable.

I am not sure I fully understand what you are saying. 

If you believe that different requirements may lead to different results
then you are essentially with me. 

Two examples: 

* EAP Channel Bindings: I mentioned that I was not able to find anyone in
the cellular industry that was interested in this. 
Does it mean that the work will not be done? No, because folks argue that in
the university space and enterprise environment it could be useful. 

* TLS and TCP for RADIUS: Most folks in the cellular space don't care about
this because they are specifying Diameter all over the place. 
As we have learned, folks working at the universities have different
constraints and needs (e.g., using software that is downloadable for free
from the Internet as a basis for their AAA deployment). As such, they like
this new work as it will solve their problem without switching to commercial
solutions or to switch to OpenDiameter etc. 


>
>> I believe I can say that because I was a victim of "strictly 
>applying"
>> the guidelines as they are, despite the examples provided in the 
>> document on EAP etc.
>
>This harkens back to the age old debate on whether RADIUS 
>should provide facilities to encode complex / structured data. 
> This debate is as old as
>the RADEXT WG itself.   The current RADEXT WG consensus is that RADIUS
>doesn't need extensive "structuring" facilities, and that the 
>simple "grouping" facilities, e.g. of the Extended Attributed 
>draft, is sufficient.

At least I am asking to capture these aspects in the draft as there are
really two types of complex attributes, namely those captured with the
RADIUS extended attributes draft and then more complex onces that can be
found also in the Diameter space. Reading through the draft one could easily
get the impression that that document now allows the Diameter AVP structure
to be easily supported, which is not true. 

>Yes, this is far short of Diameter's capabilities, but we 
>decided that RADIUS should not be extended to maintain feature 
>parity with Diameter.

It is fine not to align it 100% with Diameter. I just want the differences
to be documented in the document. 

>Otherwise, why maintain both AAA protocols going forward.  :-)

There are many reasons -- none of them have anything todo with technical
arguments. 

>
>>>> I am not even sure that it is always the right way to put such a 
>>>> section in a RADIUS document when they authors do not envision 
>>>> Diameter to be used in their specific environment.
>>>
>>>What do you suggest?
>>
>> Based on the discussion we had at the AAA doctors meeting I 
>will think 
>> about some way forward.
>
>Thanks!
>
>>> Please elaborate...
>>
>> The above statement makes the assumption that the parsing happens in 
>> some C-alike language that was used to implement the entire RADIUS 
>> server. There are indeed issues when you touch this code.
>>
>> However, most AAA servers have an abstract language they use for 
>> handling of msg processing. This language is typically not C and 
>> written in a way that it does not lead to security issues. As such, 
>> even additional parsing that has to be implemented it does 
>not lead to 
>> any interoperability or security problems.
>
>Hmmm...  "Most"?  The metric we have been using is the "data 
>dictionary driven" server, which is admittedly a fairly old 
>implementation technique.

Using a dictionary based approach is not a bad thing and will work for many
cases. 
The question is only how powerful the language for the dictionary has to be.
It could be just a "attribute name", "attribute code" and "data type".  

Regarding the "data type: Looking at the dictionary provided with FreeRADIUS
I noticed that there are datatypes support that are not listed in the RADIUS
Design Guidelines document.

Additionally, FreeRADIUS support some form of scripting also in addition the
to the dictionary, see http://wiki.freeradius.org/Configuration. 


>Such servers may have auxiliary "policy servers" that make 
>more complex decisions about authorization data than is 
>possible with simple attribute matching schemes or user group 
>membership schemes.  The relevant point of discussion, 
>however, is the on-the-wire RADIUS message format.

I am not saying that everyone should come up with the most complex attribute
formats. 
If one can avoid a custom attribute format then this is certainly
appreciated as it will lower the time it takes to implement a specific
functionality.

BUT: 

* If I take certain Diameter documents and I want to provide the
same/similar functionality in RADIUS then I cannot use the "simple"
attribute encoding. Example: Diameter QoS attribute. In that case I have to
come up with my own RADIUS attribute encoding for this purpose. 

* If I have features that already require additional code at the AAA server
(like the location stuff) then it does not make a big difference whether I
have to write a few lines more or less -- I have to touch the code base
already anyway. 

Even though these cases seem to be implicitly covered by the RADIUS design
guidelines document I still got beaten up with the RADIUS GEOPRIV document. 


>
>RADIUS was designed to provision pretty simple things.  It 
>originally envisioned each attribute as having an "atomic" 
>value, not some complex, structured message.  I understand 
>that AAA servers today attempt to provision more complex 
>things, and this is wherein the friction results.
>Should RADIUS be extended, much as Diameter has, to support a 
>more complex and nuanced set of provisioning capabilities? 

RADIUS has already been extended to provide more than "simple things". 
Example: Key distribution in Wimax. 


I believe there is value in documenting what the perceived mode of operator
for a protocol is. 


> If 
> so, then why do we need Diameter? :-)

Folks use the protocol they are familiar with for their favorite purpose
(even if it has nothing todo with AAA anymore). There are certain groups
that are more familiar with RADIUS and other's that bought into Diameter. It
is just a protocol and both of them are not difficult to implement. 

So, I don't see a problem with regard to this aspect. 

>
>>> So, what you are suggesting is that the syntax and semantics of 
>>> RADIUS attributes are contextually dependent on some policy 
>decision 
>>> that is opaque to the RADIUS client, proxies, etc?  I think 
>that's a 
>>> Very Bad Idea (tm) and falls under the recommendation against 
>>> polymorphic attribute design.
>>
>> No, my argument is different. I believe that the argument 
>that complex 
>> attributes lead to interoperability, deployment and security 
>issues as 
>> stated in the draft is incorrect and can of course happen 
>from certain 
>> implementation choices.
>
>I see.  I guess I still disagree.  Yes, anything, no matter 
>how complex, convoluted and baroque can be made to 
>interoperate with sufficient attention to detail.  A pig, 
>given sufficient thrust, can be made to fly.  :-)
>
>> Most AAA server do not have these issues as they are providing an 
>> abstract language for the developer for business logic, parsing, msg 
>> handling, etc.
>
>So, you're saying that today's AAA Servers are really Policy Servers?

Yes. 

>
>I think that the basic issues here is that there is a 
>disconnect between the consensus position of the RADEXT WG (to 
>keep things pretty simple) and need you are describing to 
>provide [near] capability parity with Diameter.  
Well. I would like to hear from other folks in the group whether they think
RADIUS server implements deployed in larger networks are so simple. A
Diameter implementation can also be pretty simple if you don't make use of
certain features and extensions. 
As such, this is very little todo with the protocol itself rather with the
features that folks want to accomplish. 

As an example: Consider the work in the NEA working group that has an impact
to the AAA server. Simple? Not really. Will people use and deploy it? Who
knows. 

Ciao
Hannes

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


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