DHCP Authentication

[Marco Amadori]

On Tuesday 01 July 2008, 10:28:52, Simon Hobson wrote:

> Marco Amadori wrote:
> >  > >So our clients needs to accept only dhcp anwers from the "right"
> >  > > server
> >>  >
> >>  > and our DHCP server needs to serve only the "good" clients.
> >>
> >>  Since you won't have control over many of your clients (eg embedded
> >>  clients in devices you don't have the source to) this isn't something
> >>  you can do at the client.
> >
> >I thought that since clients receive differents DHCP answers they could
> > choose (like by requiring a particular VENDOR ID, or a DHCP variable like
> > that, to match a string) which one to listen.
>
> But you miss the point - you do NOT have that level of control over
> your clients !

MMM, yes. We prepare all our clients ( a linux embedded with busybox udhcpc, 
but we can install ISC dhclient if this enable more server 
identification). "good" clients are known, only it is unpractical to track 
MACs or to differentiate them.

The solution I come to cope to this issue is to use a different UDP port on 
both DHCP server and clients.

> If you change the port then unmodified clients won't work. Since in
> most networks the majority of clients won't have that degree of
> control, then your network simply won't work.

The clients are under our control, the switches not.

> The idea of monitoring isn't so you can reconfigure your clients*,
> it's so that you as the network admin can track down the rogue server
> and 'explain' to the person responsible why they shouldn't be running
> it (apply piece of "clue by four" ?)

We cannot do that and we should "respect" rogue dhcp:

We have our embedded linux clients on a foreing network, we cannot configure 
switches, and we cannot even blame non malicious rougue dhcp users (and 
probably even malicious). We can add our servers and clients to the network. 
We have control on which software runs on all our clients and servers.

I know it is a strange network setup.

> * The point of DHCP is to avoid having to configure clients manually
> - other than setting hostname (or if they supported auth, the server
> key), then you don't really want to be manually messing with their
> settings.

We would like to setup just the hostname one by one by people which deploys 
the clients (a not techical installators which just can enter few numbers on 
a remote control from which we generate hostnames like "room-234"), and have 
other settings the same among our clients.

So far my best ideas are:

1 - use a different UDP port on client and servers
2 - identify clients by MAC prefix (all our clients share the same first 
triplets assigned to our firm)
3- assign differents subnets in order of hostname

I already tried the above 3 points and found it working, I was asking a more 
complete (hence RFC or key auth/ident) a secure solution.

Moreover since I need to give clients 44 different subnets based on hostname I 
used a bash generator to produce a settings like the one below, I wonder if I 
can extract substrings from a variable (like the hostname) and generate just 
1  rule to do subclassing:

----- dhcpd.conf -----
[...]

class "west-wing-02" {
        match if (substring (hardware,1,3) = 00:0x:0x)
                and (substring (option vendor-class-identifier, 0, 9) 
= "my-board")
                and (substring (option host-name, 0, 9) = "room-0023") ;
}

[...] ~40 of this

class "east-wing-22" {
        match if (substring (hardware,1,3) = 00:0x:0x)
               and (substring (option vendor-class-identifier, 0, 9) 
= "my-board")
               and (substring (option host-name, 0, 9) = "room-0224") ;
}

[...]
subnet 10.30.0.0 netmask 255.255.0.0 {
        option broadcast-address 10.30.255.255;
        option subnet-mask 255.255.0.0;
       
        pool {
                # test east wing
                allow members of "east-wing-02";
                range 10.30.4.101 10.30.4.199;
                option subnet-mask 255.255.255.0;
                option broadcast-address 10.30.4.255;
        }
	[...] ~40 of this
	pool {
                # test east wing
                allow members of "east-wing-22";
                range 10.30.24.101 10.30.24.199;
                option subnet-mask 255.255.255.0;
                option broadcast-address 10.30.24.255;
        }
}

The foreign switches (level 3) will do the proper routing, 1 different subnet 
per "wing", MACs 00:0x:0x are mangled by me.

-- 
ESC:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.