IPv6 accounting RADIUS SQL schema?

[Alan DeKok]

On Aug 19, 2018, at 3:56 PM, WAGHORN, Jason (NHS BORDERS) via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
>>> i.e. have FreeRADIUS handle DHCP, too.  On initial request, it can check the MAC address in
>>> radacct for the username who last logged in.  Then, check their billing history.  If their
>>> account is in arrears, give them an IP from a walled garden.
> 
> How will this work (either way) if the client supports MAC spoofing?

  All clients support MAC spoofing.  But you don't really care what the MAC is.

> Surely you should prevent access via username, not client MAC (they could also just use another client, or W-NIC,...)

  I *did* mention RADIUS first, then DHCP.  That gets you a User-Name.

  Let me be clear, seeing as my point didn't get across:

  RADIUS gets you User-Name, MAC address, NAS IP, and NAS port.  You can authenticate the user (PAP, CHAP, MS-CHAP, EAP), and store the MAC, NAS IP and NAS port in the radacct table.

  And yes, you don't really care what the MAC is.  Because you authenticate the user by name && password.

  When you get a DHCP request, you get MAC, NAS IP, and NAS port.

  Hmm... it seems like we have already seen that information!  What happens next?

a) the MAC , NAS IP, and NAS port match something in radacct.  You can now look up the User-Name, and assign IPs based on user groups.  Or, check the users billing status, and assign an IP from the "walled garden" pool, with the walled garden router / captive portal.

b) the MAC, NAS, IP, and NAS port *don't* match something in radacct.  You can use this mismatch as definitive proof the user is doing something stupid.  And... (drum roll) put them into a walled garden.

  There are no other possibilities.

  If the user behaves correctly, everything works and they get online.  If the user misbehaves, they don't get online.

  > Seems to me like a game of whack-a-mole :)

  I don't see how.  What part of the above won't work?

  Hint: I've done this in production systems.

  Alan DeKok.