On Oct 9, 2013, at 11:53 AM, Ted Lemon <Ted(_dot_)Lemon(_at_)nominum(_dot_)com>
wrote:
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.
Hard coding it means you can't make your device work if you are on a network
that behind a firewall that does not allow the traffic or is on a networks that
is not part of the internet or is being set up for use in emergency
communications where the the device is on a network say in Hati that has become
partitioned from rest of network after an disaster. Obviously one can fallback
to a hard coded option if no DHCP option is found but it's pretty important to
have a chance of being able to configure things to work on networks with less
than ideal connectivity.
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.
I think this is the part where we disagree. I don't think you get the same
effect if the DHCP server did the lookup and returned a single IP address. I
realize you understand DNS better than me but DNS returns a lot more than a
single IP address. In the most simple case it can be returning a list of IP so
that if one server is down, the client can contact another. I don't see how to
do that with single IP returned from DHCP. (yes, I realize that some people
have requested DHCP options to return a list of IP). But more impotently if
someone wants to do something like move the server from one data center to
another, it is well understood by admins how to do that when clients access the
server by FQDN. It's much harder when it's an IP address that has to be updated
in DHCP servers. Not to mention opening up the use DNS tools like SRV and
NAPTR.
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.
This is not really a constrained device issue - it has to do with hosts that
don't have an IT administrator and need to just work. They might be
constrained, but right now my house has devices doing DHCP, DNS, and HTTP all
fitting in 12 k of flash, 512 bytes of ram, and an 8 bit processor at 16Mhz so
don't think that DNS needs to be big - probably not fully standards compliant
but it works. My house also has things like NAS, WiFI GW, TVs etc that have
pretty powerful computers yet still need to turn on and just work with no
administration.
Probably not a hugely bad thing, but that depends on the device. A device
with severe constraints probably isn't using DHCP anyway.
Seriously ? How do you think IPv4 constrained devices get an IP address?
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 co!
mpromise 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.
Hmm - this is much more interesting - help me understand what part it does not
follow 3315. When it boots, it uses DHCP to find the address of a configuration
server. If it needs a configuration, it downloads that from the configuration
server. If it does not need a configuration, it does not download it. I would
not be shocked to find out that this was not following 3315 but I think I can
speak for at least most the folks doing this that they did not know it was not
consistent with 3315 and would be very interested in hearing why.