AAA and future Diameter support, questions

[Sebastien Decugis]

>> I am concerned by the fact that we might be limited by RADIUS
>> capabilities in that case. If at some point some extension is added to
>> Diameter but not RADIUS, this implementation would be unable to follow.
>>     
>
>   It's RADIUS.  If you need to butcher the protocol... go right ahead.
> It's easy to define vendor-specific attributes with vendor-specific meaning.
>   
Ok, I see, thank you for the information.

>> It also adds some work to encapsulate / decapsulate in RADIUS messages.
>>     
>
>   Any idiot can do that.  I've done it a number of times, and even got
> it right some of those times. :)
>   
Sorry, my bad. I meant: it adds work for the deamon on every packet,
wasting memory and CPU cycles. Maybe it's not so much, I am not familiar
with RADIUS protocol.

>   There are other options:
>
>   1) re-use the radius code in hostapd
>
>   2) BSD licensed freeradius client:
> 	http://freeradius.org/freeradius-client/
>
>   3) a LGPL'd library, that's more complete:
> 	libfreeradius-radius.a
>
>      It's part of the main "freeradius-server" distribution, and isn't
> broken out into a separate package.
>
>   I wouldn't suggest writing your own RADIUS implementation at this point.
>   
Thank you for these useful pointers. I will look into these
implementation and decide after...

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)