Shut Up, Laura

A quandary was blogged by my esteemed Best Man, the short version being: how can you prevent Virtual Machines (that are being stood up for DevTest and not for prod use) from chewing up all of the live IP addresses in a DHCP scope?  The short answer, clearly, is "Configure all new VMs with NAT'ed IP addresses", but not everyone is going to follow that credo.

This question interests me and has been churning in the back of my head, so I'm brain-dumping as much for my own mental exercise as anything else.

Can Active Directory help with this?  Not as such, or at least not in its current incarnation, since by the time AD gets involved in any sort of auth transaction, the VM already has its IP.  ("If you can read this Domain NC Head, you're driving too close"?)  Also doesn't help if the machine isn't in any way domain-joined.

Can DHCP help? In its current incarnation, not without DHCP reservations, as far as I can think, and no way does that scale.  20 DHCP reservations?  Easy to manage. 8,000 DHCP reservations?  Yeah, let me know how that works out for you. 

So, can you bolt something onto a DHCP implementation that will interrogate a requesting client (WMI query for a motherboard type that isn't of vendor 'Microsoft' or 'VMWare' or something) before handing out an IP address?  Clearly not in its current incarnation, so let's pretend we can build something that can. Safe to say, that would completely alter DHCP as we currently understand it, as I can't imagine the DORA¹ conversation could emulate that kind of intelligence.  It also pre-supposes that your DHCP is running in a security context that can interrogate each requesting machine before handing out a lease. Might work in a highly-managed environment, but would be massively difficult to enforce in a more fluid dev/test world. (Or, extending the metaphor, in an unmanaged space like a college dormitory or something.) I also imagine even if you could do it, it would probably be ridiculously easy to circumvent by whacking at the virtual OS that's being queried by this hypothetical DHCP that we just built.

Moving along.  Port-level controls, a la 802.1X?  I'm reminded of something that's already being done by a number of Universities, where if a switch detects a new MAC address on a port, it quarantines and redirects the user to a web-based registration app (see NetReg) prior to allowing full network access.  The raison d'etre in higher ed is to maintain a database of contact info in unmanaged areas like student dorms, where if someone is worm-infected and blasting the entire campus or is Napster-ing 20GB of data a night, Network Engineering or Information Security knows whose door to come knocking on.  Could institute a similar process here that quarantines everything across the board, and grants access to only those MACs that have made it through whatever approval process you define.  But then you've got yet. another. data store. of valid vs. invalid MAC addresses to maintain/back up/age/scavenge (spoofing opportunities galore, plus, is storing any of this data a violation of privacy policy?), and how badly is inserting this process going to impact people operationally, if they're WDS'ing dozens or hundreds of VMs at a go for testing?²

Methinks that some way, somehow, this becomes a job for NAP, where any new machine that gets plugged into the wire and meets % CRITERION % (however we're defining the way a machine is recognized as a VM, I'm just gonna hand-wave around that bit) gets shunted into a private-IP'ed VLAN.  Might not even necessarily need to be user-impacting, you can just hand them a NAT'ed 10.0.0.0/8 with Internet access and you will have protected the user from their own stupid user tricks. In effect, you are doing the NAT'ing for them if they do not choose to do so for themselves.

Clearly this assumes some supporting network infrastructure (routing between multiple VLANs, VLAN tagging, etc.), and assumes that the host machine can understand some form of virtual switching, since you'd have the host on one VLAN and the guests somewhere else.  (I know that ESX allows you to do virtual switching OOB, haven't played with Hyper-V so I don't know if there's equivalent functionality.)  Probably also assumes some NAP enforcement pieces that aren't in existence at the moment, but that's what open API's are for.

At the end of the day, is it worth what appears to be not-insignificant effort to fix this problem?  That, my friends, is a business decision...I'm just a nerd jotting down notes on my proverbial restaurant napkin here.  :-)

[1] DHCPDISCOVER - broadcast packet sent by a booting client to the local subnet

      DHCPOFFER - broadcast packet sent by every DHCP server (if there's more than 1 in hearing-range) to the client, offering a lease

     DHCPREQUEST - unicast packet sent by the client to the 1st DHCP server whose DHCPOFFER came in

     DHCPACK - unicast packet sent by the DHCP server to the client, confirming the new lease

[2] "Napstering", "WDSing". I seem to be good at making up verbs today.