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