AAA and future Diameter support, questions
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:
> 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...
Network Architecture Group
More information about the Hostap