Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cafbit.com

Post reply on HN
Print view View original

111–120 of 191 posts

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

#111

Post by sedev »

tzs wrote: post #95
jarek wrote: post #85

Earlier quoted context omitted.

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…

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.

That's where I'm at with this. What Jarek describes can happen, but that's a failure case, not the normal-operation case. And as portrayed in the article, the engineers at Apple have accounted for the failure case, so all's well. They simply have made the very reasonable assumption that the DHCP server will normally be operational, not in a crisis state, and that it will honor its contracts as specified in the RFC. How hard is this?

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

#112

Post by tomlogic »

cbs wrote: post #66
tomlogic wrote: post #47

Earlier quoted context omitted.

Regarding your security statement, I didn't get that from the packet capture. The Mac is sending an ARP request for the IP addresses of the DHCP servers of networks it's been on recently. An attacker would need to know the correct MAC address to respond with -- the Mac is not sending that out in the request. If the ARP comes back with the cached MAC address for that network, the Mac continues using the valid DHCP lea…

the Mac is not sending that out in the request. I could be wrong about this, as I haven't analyzed actual arp requests in ages, but from the article it appears the arp requests are unicast to the (at least in the example) cached MAC for the gateway.

Ah, after a closer look at the original article, I see that now. Curious that Apple would choose to unicast those requests.

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

#113

Post by jarek »

rlpb wrote: post #107
deskamess wrote: post #96

Earlier quoted context omitted.

I think your description is correct. The problem is the impact of the false "ip conflict" that is caused by this optimization. A device that detects an ip conflict should not have to guess whether it is an ip conflict caused by an optimization on another device. As pointed out in other comments an ip conflict can cause other systems to drop existing connections. No one likes ip conflict notifications, or to have thei…

The problem is that the DHCP server re-issued a valid lease to a second computer. Surely this is an issue with the DHCP server not playing nice, rather than Apple?

Do you feel there is a better, more tolerant, and less error prone course of action the DHCP server could take if it runs out of leases?

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

#114

Post by saurik »

brigade wrote: post #106
saurik wrote: post #98

Earlier quoted context omitted.

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 go…

You don't even need to cycle MAC addresses; just send DHCPDECLINE messages for any address the server gives. DHCP requires that any address that elicits that response from a client MUST be marked unavailable, and provides no provision for it ever becoming available again. Ignoring the client is the only automatic mechanism DHCP provides for countering this. You have to remember that DHCP was written back when it was…

I'm confused... are you therefore suggesting that this is how people like Linksys should handle this problem? I fully realize that the spec was written in another time, but I don't think tzs did: he is actually citing the spec as a reason why these leases should stay around. When you go to a coffee shop, the router does not and probably should not play a chime when it has run out of DHCP leases, causing the barista to go around the room finding laptops that have been setup incorrectly... the router should, and almost certainly does, just "figure something out", likely by reclaiming addresses.

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

#115

Post by saurik »

Locke1689 wrote: post #110
saurik wrote: post #98

Earlier quoted context omitted.

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 go…

It's trivial to DoS any layer 2 network. This is trivial netsec.

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."

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

#116

Post by Locke1689 »

saurik wrote: post #115
Locke1689 wrote: post #110

Earlier quoted context omitted.

It's trivial to DoS any layer 2 network. This is trivial netsec.

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.…

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.

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

#117

Post by saurik »

Locke1689 wrote: post #116
saurik wrote: post #115

Earlier quoted context omitted.

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.…

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.

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.

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

#118

Post by jarek »

sedev wrote: post #111
tzs wrote: post #95

Earlier quoted context omitted.

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.

That's where I'm at with this. What Jarek describes can happen, but that's a failure case, not the normal-operation case. And as portrayed in the article, the engineers at Apple have accounted for the failure case, so all's well. They simply have made the very reasonable assumption that the DHCP server will normally be operational, not in a crisis state, and that it will honor its contracts as specified in the RFC. H…

There is that principle of "conservative in what you send, liberal in what you accept" on which UNIX and half of the internet was built.

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

#119

Post by shinratdr »

sid0 wrote: post #94
shinratdr wrote: post #92

Earlier quoted context omitted.

The only reason that is a useful example to you is because that act is genuinely dangerous. There is nothing dangerous about swiping someone's IP and causing them to have to reconnect.

And yet it is exactly as dickish and disrespectful of others. Just like Apple as a whole, it seems.

Meh. Treating developers and the back end gingerly results in no benefit for consumers, in fact by and large it results in in a pretty clear loss.

Characterize it however you wish, as a user I'm going to go with the platform that focuses on pleasing me rather than making the lives of other users or developers easier.

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

#120

Post by shinratdr »

jarek wrote: post #103
shinratdr wrote: post #92

Earlier quoted context omitted.

The only reason that is a useful example to you is because that act is genuinely dangerous. There is nothing dangerous about swiping someone's IP and causing them to have to reconnect.

You're right. I guess it's more comparable to walking up to a checkout or a cash register without looking to see if anyone is waiting in line. Great UX if you don't look around you.

It's really not. There is no real world comparable act, frankly. It is what it is, and what it is is not a big deal.
Post reply on HN