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

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

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?  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 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.
Yes, this is far short of Diameter's capabilities, but we decided that
RADIUS should not be extended to maintain feature parity with Diameter.
Otherwise, why maintain both AAA protocols going forward.  :-)

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

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?  If so, then why do we need
Diameter? :-)

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

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.  



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