AAA and future Diameter support, questions

Sebastien Decugis sdecugis
Thu Feb 5 00:24:42 PST 2009

>> 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:
>   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 Decugis
Research fellow
Network Architecture Group

More information about the Hostap mailing list