Using Nas IP Adress as client "key"

[Timothy]

Depending on your hardware, you might want to try radsecproxy.  It does
currently have a 16 character password limit though

Johan Meiring wrote:
> Hi all,
>
> The radius spec currently identifies a Nas (client) by the Nas's IP
> address
> (Packet-Src-Ip-Addres?).  That is how radius works.
>
> We have a bunch of hotspots out in the field which could be behind any
> kind
> of internet connection.  Broadband/Dynamic IP, natted, etc.
>
> Because we have no idea where a spesific Nas's traffic might come from
> we've
> implemented dynamic-clients.  Using rlm_raw we use the Nas-Identifier
> to lookup the shared secret in a database, and the client gets
> dynamically created.  (Thanks Alan for the help with this one!!)
>
> This works very well, but has a few irritating (not showstopping) side
> effects.
>
> 1)  Sometimes we have more than one Nas behind the same natted
> connection.
>     This means that they all have to have the same shared secret.
>
> 2)  Also it happens that a different Nas ends up behind a previous Nas's
>     IP (dynamically assigned broadband IP) and then the shared secret
>     is again rejected.
>
> Within a corporate/large telco's network, the Nas's (802.11x switches
> or Dslams) are generally behind fixed IPs,  but for the hotspot world
> any Nas source IP goes.
>
> Is it not a maybe a good idea to start considering a different "key"
> to identify the Nas by.
>
> In clients.conf (or for dynamic clients) a paramter ("nas-key") that
> could be Src-IP or Nas-Id.  i.e. you can choose the "key" that
> identifies a spesific Nas/client and therefore the shared secret.
>
>
> Does it sound like a bad idea?
>
> How difficult would such a change in Freeradius be?
> (I've not read the source code yet, just throwing an idea out there).
>
> Opinions?
>
>
> PS:  I realise that tunneling the radius traffic is a different
> solution to the same problem, but in our case not always easy to
> implement.  (The only extra "layer" I would love to see is RadSec.)
>
>