AAA and future Diameter support, questions

[Sebastien Decugis]

Hi,

Thank you for your quick reactions.

>> I would need to better understand what are the reasons for an external
>> process.
>>     
>
>   Diameter is... huge.  It seems to me that separating the two this way
> means minimal changes to hostapd.
>   
That is the main reason.

Also, I'd like to keep the possibility of having one physical node
handle several Diameter applications: not only EAP but also SIP or
something else... For this matter, I use a daemon that provides the base
protocol support, and dynamic extensions that add support for each
applications. I want the EAP support to be such an extension. If you
want to see more about this Diameter implementation, please look at my
project homepage: http://aaa.koganei.wide.ad.jp .

>> In general, I would prefer to do this within hostapd process,
>> but if there is justification for doing something with an external
>> process, that can be a valid design, too. Anyway, making the AAA ops
>> design easier to replace in hostapd certainly makes it easier to add
>> this type of mechanism and/or other Diameter implementation, if desired.
>>     
>
>   My one concern would be the "hostapd" transport that is used over this
> pipe.  It will be a new protocol, which will require maintenance,
> versioning, etc.
>
>   It might be simpler just to use <cough> RADIUS as the transport.  It's
> known to work to transport EAP.  If the aren't many *more* requirements
> for this effort, RADIUS would seem to be a natural fit.
>   

You are right about this, I am not sure yet how to exchange data between
both processes. RADIUS sure looks an attractive choice, with the bonus
that it would directly provide a RADIUS/Diameter gateway for this EAP
application (well, only need to change UNIX socket for INET sockets ^^)
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 also adds some work to encapsulate / decapsulate in RADIUS messages.
On the other hand, the "protocol" has to transport: EAP messages, key
material, eventually some configuration options and error codes. It
would not be very complex. Maybe just sending the data encapsulated in a
TV or TLV is enough, and quite easy to implement and extend... Well, I
am not decided yet. If I go for RADIUS use, would you help me for the
decapsulation part? :)

Best regards,
Sebastien.

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