On Oct 9, 2013, at 9:47 AM, Ted Lemon <ted(_dot_)lemon(_at_)nominum(_dot_)com>
wrote:
On Oct 9, 2013, at 11:26 AM, Cullen Jennings (fluffy)
<fluffy(_at_)cisco(_dot_)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 compro!
mise 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.