←back to thread

Rapid DHCP: Or, how do Macs get on the network so fast?

(cafbit.com)
354 points timdoug | 4 comments | 12 Jul 11 17:04 UTC | HN request time: 0.022s | source
Show context
saurik ◴[12 Jul 11 17:52 UTC] No.2755677[source]▶
> This network recognition technique allows the Mac to very rapidly discover if it is connected to a known network. If the network is recognized (and presumably if the Mac knows that the DHCP lease is still active), it immediately and presumptuously configures its IP interface with the address it knows is good for this network.

Ok, seriously? That isn't a bug in an implementation somewhere, but in fact a feature that Apple actually is proud of? Am I the only one who finds that if you get a room full of people sitting around with Macs at least one person gets their IP address stolen by someone else?

(edit: I just got downvoted, and then asked the people in the room with me, and they seemed to agree with my perceived correlation regarding the "another computer is using 192.1.0.1" issue... instead of just downvoting, maybe reply? It is actually quite common that DHCP leases on a network get reset for various reasons, and if you just jump on the network without revalidating your lease, you are actually quite likely to just "presumptuously" steal someone else's IP address.)

replies(11): >>2755698 #>>2755761 #>>2755851 #>>2756177 #>>2756303 #>>2756333 #>>2756755 #>>2757385 #>>2758088 #>>2758576 #>>2758677 #
sedev ◴[12 Jul 11 21:48 UTC] No.2756755[source]▶
I think that you're wrong because, basically, if that 'steal an IP address' scenario happens, it means that the DHCP server has in some way broken its promises. That _happens_ in production environments, but I'd much rather clients use behavior like this, that assumes that a DHCP server will keep its promises about things like lease length, than assume the worst about the DHCP server. The clients should first assume that the server will keep its promises, and only on evidence that it hasn't, seek alternatives.
replies(2): >>2756799 #>>2757700 #
jarek ◴[12 Jul 11 21:59 UTC] No.2756799[source]▶
So here's my understanding of the situation: when a DHCP server runs out of leases to assign, it will kill the oldest (in terms of use) lease. If the device that held the lease is not on, for relevant values of "on", at the time, it will not be notified about this.

The usual (perhaps standard, I'm not sure) process has the device confirming its DHCP lease when coming back on, and in this situation the device would be notified that it can't have the old lease as it's been repurposed, and the server will provide another lease (perhaps after killing some yet another lease).

If this is an Apple device and it behaves in the manner described, after coming back "on" it will not consult DHCP, but rather it will reuse the lease it held previously. If the server has given that lease to another device, the Apple device will butt in, causing an IP conflict. Perversely, the Apple device will shortly discover this, actually do a DHCP request, and switch over with no indication to the user, leaving the other device to wonder why it had an IP conflict and how to handle it.

Is this incorrect in any way?

replies(3): >>2756984 #>>2757020 #>>2757447 #
tzs ◴[12 Jul 11 22:55 UTC] No.2756984[source]▶
As far as I can see from the RFC and from Googling, there is no mechanism for a DHCP server to take back an IP address before the lease has expired, unless the client explicitly initiates relinquishing the lease.

Once the address is given out, it is the client's for the term of the lease.

replies(2): >>2757027 #>>2757219 #
saurik ◴[12 Jul 11 23:07 UTC] No.2757027[source]▶
Given that most routers are managing a class C network, and even then have allocated the first 100 addresses for internal use (starting the DHCP pool at .100), this would mean that it would be trivial to DoS any DHCP server in seconds by simply cycling MAC addresses and leasing all of their addresses.

Obviously, this is not realistic, and no one would ever implement a DHCP server that allowed this to happen: it is going to keep track of some fixed number of leases (probably/hopefully as many IP addresses as it is managing) and, when it runs out, it will be forced to reclaim an address from another user.

If anything, the fact that such a mechanism is not specified is simply going to make this "worse", as the specific implementation of how and when the reclamation happens is going to end up as "whatever makes sense to the guy working on that specific DHCP server implementation", and may constitute seemingly random behavior.

replies(2): >>2757164 #>>2757217 #
1. Locke1689 ◴[13 Jul 11 00:14 UTC] No.2757217{4}[source]▶
It's trivial to DoS any layer 2 network. This is trivial netsec.
replies(1): >>2757271 #
2. saurik ◴[13 Jul 11 00:36 UTC] No.2757271[source]▶
There is a fundamental difference between sitting on the network flooding it (an activity that requires you to actually be connected to the network, although this could of course be a small and difficult to detect device), and sending 256 packets and walking away, content in the knowledge that for the next 24 hours no one will be able to use the network because you own all of the DHCP leases. "This is trivial netsec."
replies(1): >>2757284 #
3. Locke1689 ◴[13 Jul 11 00:41 UTC] No.2757284[source]▶
I never said flood, I said DoS. I don't think this is on-topic so I'm not going to go in to detail but you should Google ARP spoofing. These tactics are quite trivial and I'm teaching undergrads to do it next year.
replies(1): >>2757298 #
4. saurik ◴[13 Jul 11 00:46 UTC] No.2757298{3}[source]▶
I was, and continue to be, under the impression that this kind of attack is not possible when an access point has node isolation (a very common feature that even my MiFi router supports, despite it often being turned off in home and even office environments), yet the aforementioned protocol-level DHCP DoS I described would work on any device that implemented the DHCP specification. I therefore fail to see how ARP spoofing is relevant. Remember: we are discussing whether it is a fair belief that any reasonable implementation of DHCP would have implemented the spec as stated.