On Oct 9, 2013, at 1:32 PM, Cullen Jennings <fluffy(_at_)iii(_dot_)ca> wrote:
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.
An AFTR IP address is like a router IP address, but for a particular IPv4
transition technology. Other transition technologies of this sort are classic
examples of services that make sense to configure with DHCP, because they are
part of the network infrastructure.
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 .
Apple hard-codes the FQDN of a set of NTP servers they control into all their
products. I think other OS vendors do as well, but am not clear on the
details. The advantage of doing this is that you can then authenticate your
communication with the NTP server. If you use DHCP to configure your NTP
server, you cannot validate your communication with your NTP server. Of
course there's a bit of a chicken-and-egg problem here in terms of replay
attacks and key repudiation, but in principle you get more security if you hard
code the FQDN of your NTP server than if you use DHCP to configure it.
Of course there are cases where this doesn't matter, and DHCP is just fine, but
I can't think of any other than perhaps a self-setting wall clock.
Of course, if a CPE vendor were to hard-code the FQDN of an NTP server
belonging to someone else into their devices, that would be disastrous.
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'd get the same effect if the DHCP server did the lookup. I agree that if
you want to suddenly add an NTP server and need it to be adopted in a time
frame shorter than your typical lease time, and your DNS TTL is shorter than
your typical lease time, you will get better service using DNS, but there's no
clear win here—this would be a pretty weird requirement.
You agree that FQDN is would be a better design than IP for NTP ?
No. I think the boxes that need NTP configuration via DHCP are most likely
constrained devices, and that requiring them to do a DNS lookup in addition to
the DHCP transaction is unnecessary. Probably not a hugely bad thing, but
that depends on the device. A device with severe constraints probably isn't
using DHCP anyway.
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
com!
promise 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 what you've done here is to invent a service configuration protocol that
leverages existing DHCP server infrastructure, uses packets that look just like
DHCP packets, but is not actually DHCP. A client that behaves in the way you
have described is not following RFC3315. It might be following the letter of
RFC2131, but that's because RFC2131 has a known bug in that it doesn't
_require_ clients to use new information they get from DHCP servers during
lease renewals.
This is not an academic distinction: I've seen all sorts of support calls and
questions about IP phones from at least one manufacturer, because these phones
do not follow the DHCP protocol specification, and their behavior is surprising
to network administrators. I didn't realize until now that this was by
design, and not just a bug in the implementation.