Stefan Winter wrote: 
Hi,

  
In my project, I don't own the hotspots, and don't know about the
hotspots ISPs.
The hotspots communicate to the radius server though the internet.
      
  I would suggest using another method to get a secure connection to
the hotspot.  Maybe IPSec.
    

this is again an example where a RadSec extension would come in extremely 
handy. Short wrapup: RadSec establishes connections via TCP and TLS and 
transports the RADIUS payload over it, so clients can be identified by their 
TLS certificate; IPs and shred secrets become obsolete. Create a dedicated CA 
for your servers, then whoever tries to connect can be checked against your 
CA root.
Make the hotspots talk RadSec and let them communicate with your FR server via 
this link.

The only open problem is: right now there is only one implementation of RadSec 
in OSCs Radiator, and it could be better coded and more advanced.

I am working on a formal specification of RadSec right now, of which I hope it 
will somehow find a way into the Informational RFC track. There is a lot more 
potential in it than the OSC Whitepaper suggests.

It would be really great to get an implementation of this in FR.

Greetings,

Stefan Winter
I finally found a solution to this problem.
I will implement myself the dynamic ipaddress compatible radius server, using the NAS-identifier attributes in requests to determine the secret instead of the ipaddress.
I will implement this in python from pyrad, a very simple radius implementation in python
For authentication, chillispot uses CHAP which is secure enough for me. (I add some additionnal secret to the password)
The accounting request protected by a secret is also safe enough for me. (at the beginning)

I am sure that this could be implemented quite easily in freeradius. Maybe I'll do it if I have performance problems.

Regards
Sophana KOK