On Oct 9, 2013, at 9:47 AM, Ted Lemon <ted.le...@nominum.com> wrote:
> On Oct 9, 2013, at 11:26 AM, Cullen Jennings (fluffy) <flu...@cisco.com> > wrote: >> Help educate me on this a bit - I don't see all the things that get >> requested of DHCP. What are some examples of things where people are request >> FQDN where IP would be better. I think having some real examples that have >> come up would make it easier to see what advice is needed. > > DNS server IP address. NTP server IP address. Router IP address (not in > DHCPv6, of course). AFTR IP address. Basically, network infrastructure IP > addresses. Well DNS and Router obviously won't work with FQDN so lets talk about NTP for a minute. (and sorry, I don't even know what AFTR IP is). I design lots of devices that have to be plugged into a network and just start working with no user interaction. Getting the correct time is often really useful to have - particularly with synchronization protocols. One approach would be to hard code that NTP server name in the the product. That is not my preferred approach because stuff goes wrong and you end up with things like http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse . Another approach is for DHCP to provide the NTP server info. I would argue that getting a FQDN of the NTP server pool is a better design for DHCP than getting an IP address because this allow DNS load balancing across the pool and allows the server IP to change over time and still not have client failures. You agree that FQDN is would be a better design than IP for NTP ? > > Bear in mind that the set of services configured by DHCP ought to be pretty > small—just things that really are local network infrastructure services, not > things that are specific to the host and not to the network. It's not even > clear to me that NTP ought to be configured by DHCP, and indeed in most cases > it is not, despite there being an RFC describing how to do it. > > Considering the case of SIP, when you configure SIP I think that's probably a > configuration that shouldn't change as the phone moves from network to > network. Agree - it does not change as phones move network to network. It is uses DHCP the first time the phone is plugged in. The whole design is around making sure the phone can go from the manufacture to the end user without ever being removed from the box or powered up be an admin. The admin configures the call control system based on knowledge about the phone and which user the phone is going to but the admin does not need to touch the phone. When the phone first boots it imprint baby duck style on a network to get the configuration information which is encrypted with that phones public key. After that the phone use that configuration information not the DHCP (unless the phone is factory reset). It's actually a lot more complicated than that because security relies on replacement of manufacture certificates with the service provider certificates to make sure a comprise of the manufactures CA only results in service provider not being able to enroll new phones but does not compromise security of operational phone network. However, the first time the phone boots, DHCP needs to let the phone know who the likely service provider might be. If the phone gets the wrong DHCP information from an attacker or wrong network, the phone fails to configure but does not suffer MITM attacks. Using DHCP for phones has been used by pretty much every IP phone manufactures and most enterprise deployments and many residential providers including folks ranging from vonage to AT&T take advantage of it. DHCP greatly reduce the deployment costs of setting up VoIP networks. We had a lot of learning from the phone deployments and I expect us to use what we learned there for how we do IoT. (I presented a paper on this at the IAB workshop on IoT). One of the things we learned the hard way was names work better than numbers. > So it shouldn't be configured by DHCP. In the case where the phone happens > not to be likely to move from network to network, you could _get away_ with > using DHCP. But a solution that would work for phones that _do_ move from > network to network would also work for phones that do not, and that solution > would therefore be preferable, particularly as an MTI solution, since it > addresses all use cases. > > As I mentioned in the IESG discussion, it is a shame that aggsrv didn't > become a working group, since it was intended to address this specific > problem, at least as I understood it. >
