Using DHCP for Authentication?
gwhiteacre asks: "I have been asked to assist a small TelCo that has recently begun acting as an ISP for it's customers having DSL and Cable connections. They currently use the DHCP config file as their authentication database. They add/del/mod the mac address in the config file for each change, stop and start the dhcpd, and are rapidly discovering that this is not a scalable or sustainable approach. I have spent several days researching alternate forms of DSL/cable authentication and am not finding much. My current 'best thoughts' are to put a wrapper around DHCP to intercept the request, check a database, and then call dhcpd. Has anyone dealt with this or a similar issue, and can point me in a good or alternate direction."
See the subject.
...). It works over almost anything (ethernet, atm, ...).
It can assign ip adress, includes secure scheme for authentifications, well implemented, easily integrated with radius for more advanced stuff (DB, accounting,
#include "coucou.h"
I don't think you can "wrap" dhcpd. The protocol is a connectionless / stateless broadcasting system. I suppose you could listen for the packets, but by the time you launched dhcpd they would already be gone.
A quick google search reveals DHCP Turbo might do what you need. A Linux or Win32 based DHCP server running against a DB. But it seems to use it's own DB, not very flexible.
Of course, you could write your own DHCP server too. It's standardized. (See the RFC)
I work for a telco that was in the same situation in June of 2000. I elected to go with DHCP/bridge1483 because:
:\ You'd be suprised how much damage a little 'fat finger' can do when you're restarting your dhcp server as well as how many people really don't understand what a valid MAC address is.
/pointer
* it cost less - (PPPoE clients aren't cheap; yes, I know about raspppoe, but it doesn't run on some platforms last time I checked)
* has fewer things that can break (nic, driver, ?), hence lowering support costs
* doesn't require any software installation on any platform that I know of (almost any modern os has a DHCP client; yes, XP ships with a PPPoE client)
* gives users more bandwidth/has less layer 2 overhead (I did some research then (06/2002) and what I found seemed to indicate that the processing overhead (yeah, yeah, get a faster CPU), and layer 2 overhead of PPPoE were noticeable bottlenecks when compared to 1483. Anyone care to drum up some links (for or against!), I don't really have the time.
We setup a mysql db with all the fields we needed and I wrote a perl script that runs under cron to rebuild the dhcpd config every 5 minutes. I really need to set this up with timestamps so that it only rebuilds when things are changed, but I haven't gotten around to it yet (bad me!). I paid a friend (because I didn't have time) to write the php interface to the db and we give our tech support guys access to the db. NOTE: filter the mac/IP address fields for valid values or you will break your config.
With that said. I've enabled option-82 relaying on all of the devices between our 'DSL router' (RedBack SMS1800) and the dhcp server. I'm now getting the ATM circuit-id for each customer in the relayed dhcp discover packets. When I get the time, I'm going to switch authentication to circuit-id so that customers don't have to call in every time their MAC changes (new pc; new nic) and to streamline the install process (nobody has to call in and tell our techs their MAC. The account would just work once provisioned.
We're up to (insert random low 4 digit number) users and not having any problems with it. If you do go with redback (if you have a cisco/juniper, just get an atm blade for it...), make sure you enable secured arp and get the SRAM card to cache the arp tables for maintenance reboots. Secured-arp will stop people from using a MAC that the dhcp server hasn't sent a 'dhcp ack' to. Secured-arp, coupled with 'deny unknown clients' in your dhcpd.conf should resolve issues like that. I'm sure cisco/juniper routers support secured-arp, but I haven't had the need to set it up on mine, so I don't know.
Just my 2c. Good Luck!
[%- PROCESS life -%]