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

[Alan DeKok <aland@deployingradius.com>]

Hannes Tschofenig wrote:
> 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. 

  The WiFi roaming people are interested in this.  It permits them to
extend the enterprise environment across global roaming consortia.

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

  The WiFi roaming people are also interested in this, especially to
simplify connections (avoiding IPSec), and to minimize lost packets in
EAP sessions.

>> Otherwise, why maintain both AAA protocols going forward.  :-)
> 
> There are many reasons -- none of them have anything todo with technical
> arguments. 

  "Install base". :)

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

  Yes.  One word: WiMAX.

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

  It has a simple policy language that is not Turing complete.  The
policy language also cannot (currently) decode attributes of complex
format.  The data types are still dictionary driven.

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

  I agree.

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

  Hmm.... I would beg to differ. But that's not part of this discussion.

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

  Yes.

> A
> Diameter implementation can also be pretty simple if you don't make use of
> certain features and extensions. 

  No opinion... I lack sufficient experience.

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

  NEA is complicated.  See the NEA list archives for my opinions.

  That being said, it will likely get implemented... like WiMAX.

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