Re: [dhcwg] Pre-determining DUID

[Chuck Anderson <[e-mail]>]

On Sat, Oct 10, 2009 at 03:48:25PM -0700, Ted Lemon wrote:
> It seems that you want to use the client id as a token to identify a  
> particular piece of hardware for some purpose, but you haven't said what 
> the purpose is.   It also seems that you are (perhaps without realizing 
> it) proposing that we break a bunch of protocol functionality for 
> everyone in order to solve a problem that is specific to your 
> application.

I don't see how it breaks protocol functionality to provide 
additionaly information in a DHCP packet in order to identify and 
classify a client.

> Rather than starting out with the solution, could you please clearly  
> state the problem you are trying to solve?

Here are the problems we have that I'm sure many others share:

- Identify "known" clients vs. "unknown" clients, and other client 
classification:

We desire to only use a single identifier across IPv4 and IPv6.  
Current systems and workflows use the MAC address for this purpose, so 
it is only natural to want to use it for IPv6 as well.  I hesitate to 
use the word "authenticate", but when combined with other switch 
security features (MAC security, DHCP Snooping, IP Source Guard), the 
MAC address works great as a way to casually authenticate clients for 
access to the network and is universally supported, unlike 802.1X.

We also need to classify systems to offer different options to 
different groups of systems.

- Stability/semi-permanence of MAC addresses vs. DUIDs

MAC addresses only change/move when network hardware changes or moves 
between machines, which is a rare event, and an obvious one, done 
either by IT or the machine owner.  DUIDs are supposed to be generated 
at OS-install time and hence be long-lived/unchanging, but they would 
have to change/move when the OS is reinstalled, hard drives moved 
around, etc.  Also, different OSes or firmwares on the same hardware 
(think PXE boot) will most likely have differing DUIDs.  Finally, 
given that DUIDs aren't as “permanent” as MAC addresses, it is 
conceivable that various circumstances (bugs, troubleshooting 
procedures, uninformed or malicious users, etc.) could cause a DUID to 
change (think resetting the TCP/IP stack in some OSes).

Granted, an advantage to DUIDs is that all network cards in a system 
will use the same DUID, so we would no longer require separate 
registrations for each wired card and wireless card in a machine.  
However, we just trade that for requiring multiple separate DUID 
registrations for each OS on the machine instead, and requiring 
registration changes on OS reinstall since the original DUID would be 
lost at that point.

If we continue to use MAC addresses for DHCPv4 while using DUID for 
DHCPv6, this will cause weird situations due to the different 
scenarios under which each value changes.  Replacing the network card 
will cause v4 to break, but v6 will still work.  Swapping hard drives 
between two systems will cause the v6 registration to move, but the v4 
registration will stay with the original machine.  Tracking systems 
via MAC and via DUID will require two separate systems.  Overall, it 
seems like a very bad idea to go this route.

- Locating a system physically on the network, auditing:

It is easy to track MAC addresses on the network and find which switch 
port they are used on at any particular time by looking at the switch 
forwarding tables.  It is therefore easy to associate a client's 
physical location with the identity of the registrant.  This makes 
automated, captive-portal based registration systems easy to implement 
and integrate with other security mechanisms such as locking a MAC 
address down to a switch port.  Since we bind a user account to a MAC 
address when they register the MAC in our system, this allows us to 
track down that user and associate network activity with the user who 
registered the system.  How do we do the same with DUID?  We'd need 
some kind of new switch feature like DHCPv6-snooping with DUID 
capturing support.

- Detecting when a registration is no longer needed:

Similar to above, we can keep track of activity on the network for 
particular MAC addresses, and purge unused registrations after a 
period of time.  This would become difficult if not impossible if we 
no longer registered MAC addresses and instead registered DUIDs.  We'd 
rather not require our users to register multiple things (MAC and 
DUID), and as stated above we can automate the MAC capturing part, but 
not the DUID capturing part.

- Preprovisioning and automated deployment:

We want to jot down the MAC address of a machine from the box it came 
in (without opening the box) and pre-provision the machine on the 
network so that when it is eventually set up, it can boot up, install 
itself via PXE, and be associated with the particular pre-provisioned 
identity on the network.  We want to maintain this same identity on 
the network via IPv4 and IPv6, regardless of how many times the system 
is reinstalled or booted into multiple operating systems.

Right now, one can simply read the MAC address off a machine (on the 
box or label, or through software) and this value will never change 
(unless the hardware changes). This can be used to associate that 
specific hardware to a DHCP Class for PXE booting to a specific 
server/filename, etc. With DUIDs, the PXE boot firmware will have a 
different DUID from the OS which will generate a new DUID every time 
the OS is re-deployed. This implies at the very least that PXE booting 
will require a separate “registration”, and that the OS will need to 
be re-registered after each re-deployment.

So these are the motivations behind our desire at least to provide the 
chaddr in the DHCP packet as a way to identify and classify clients.  
As I said in my other email, we have a working prototype that does 
exactly this for ISC dhcrelay.