Slashdot Mirror
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."
Would it be possible to let dhcp serve out ip addresses, but then have a different program such as arpwatch to watch for new mac addresses, check a database, then disconnect that user. They might have access for a few seconds, but thats all. Any rouge mac addresses deteced can then be reported.
http://www.22balmoralroad.net/ http://www.tinynetworks.co.uk/
Or any other firewall that can filter on mac addresses.
Just configure dhcpd to hand out dynamic ip addresses using the range keyword.
Then either put the firewall on the same box as the dhcpd server, allowing only known mac addresses access to the dhcpd or put the firewall on the gateway between your customers and the internet.
If you pick the second option, everyone can get an dhcp lease, but only registered customers can pass. You could even set up some rules that redirect all access to port 80 for unauthorized users to a special webserver telling them they need to register or whatever.
As others have mentioned, DHCP has no authentication other than MAC, and MAC is not reliable.
But take a look at the ISC web site, and there has been a lot of work to integrate DHCP with DDNS. In perticular, there is some bleeding-edge work to crytographically secure the DDNS authentication with either symmetric or asymmetric keys. Neither is ready to deploy, though the symmetric key work requires less patching. In your situation, it may be possible for DHCP to only serve DDNS-approved addresses, all others would fail.
Though not ready it may help set a direction for the future.
But even this wouldn't stop a rogue from sniffing your network for others' DHCP packets, and using that information to guess a static IP, and run that way. As much as people dislike PPPoE-type solutions, some form of encapsulation like that or DOCSIS is the only safe way. Another option might be to have everyone run VPN software. Then route the other side of the VPN, and none of the untrusted network. Just another method of encapsulation.
The living have better things to do than to continue hating the dead.
Yep, because it adds a new encapsulation layer, so, for the same end user bandwith, it needs more real raw bandwith.
BTW, what was used before PPPoE ?
#include "coucou.h"