rlm_raw in 3.1.x

Aaron Hurt ahurt at ena.com
Wed Jul 8 02:25:31 CEST 2015


For what it’s worth we currently have several thousand APs deployed across multiple sites/states as part of a managed WiFi solution for K-12 school systems and are doing exactly what Alan has suggested.  The APs connect via RADSEC and we have a single 0.0.0.0/0 client entry which enforces TLS.  We us this in conjunction with the rlm_couchbase module to collect real-time accounting and provide captive portal authentication/guest registration.  We’ve been doing this since before 3.0.x was even officially released and it’s been working better than anticipated and scales wonderfully.

— Aaron

> On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul at freedomwifi.com.au> wrote:
>> Thanks for the response and I fully appreciate your position on it, but
>> personally think it's useful functionality that should be available if
>> someone wants to use it.
> 
>  I disagree.  Seeing as I have a strong say in what the server does, my opinion is the decisive one.
> 
>  It's not "useful" functionality.  It's insecure, broken, and wrong.
> 
>> My only current option to truly allow dynamic
>> clients is to run the dynamic clients with 0.0.0.0/0 which deems it
>> completely insecure anyway.
> 
>  That is the standard way.  And to be honest, more secure than your suggested method.
> 
>> If IP addresses of nas are constantly changing
>> then the IP isn't a value that can be used to securely identify the device
>> anyway so it becomes a bit null and void.
> 
>  Which is why RADIUS over TLS was standardized.
> 
>> We're then left processing the
>> rest of the packet to find the same data we can get from raw and just
>> rejecting the request later down the track.
> 
>  No.
> 
>> In the scenario of the public wifi service provider (eg something like
>> hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded
>> devices with limited resources so the TLS option and local proxy is just
>> not feasible.
> 
>  Nonsense.  They can run radsecproxy, or FreeRADIUS with minimal impact.  If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
> 
>> Plus it really impacts the "off the shelf" approach to
>> providing such a service.
> 
>  It's your choice to use a non-standard and insecure solution.
> 
>> Would just be nice if the option was there for those who want to use it or
>> some alternative that can provide similar functionality then we can.
> 
>  You can port rlm_raw to v3, and maintain it yourself.
> 
>  Alan DeKok.
> 
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20150708/ad5a5a24/attachment.sig>


More information about the Freeradius-Devel mailing list