On Oct 22, 2013, at 1:58 PM, Cullen Jennings <fluffy(_at_)iii(_dot_)ca> wrote:
Ted, one of the hallmarks of a successful protocol is people use it for
things it's designers think are an awful idea and it ends up working fairly
well for them. I think the heart of the issue here is that you don't believe
that DHCP should be used to configure application-layer services, like SIP.
I disagree - I think the text in the draft about when to use this is about
right
Argh. No. The hallmark of a successful protocol is not that it attracts
barnacles and gets used in ways that ultimately fail, either due to a really
bad security model, or a bad fit, or other reasons.
DHCP in fact has been very successful in the IETF as a place to add barnacles.
There are lots of DHCP option extensions that do all kinds of really exciting
things. Most of them were implemented once, shortly after publication, never
deployed, and now, if they exist at all, exist only as an attack surface that
nobody has yet exploited hard enough to cause the feature to be removed from
the client implementation.
The actual success of DHCP is its core ability to configure devices with the
information they need to get online. If you look at a typical DHCP packet
from a typical host, it doesn't ask for SIP servers. It doesn't ask for
printers. It doesn't ask about SMTP or IMAP or POP.
My DHCPv4 client asks for: Subnet Mask, Default Gateway, Domain Name Server,
Domain Name, Domain Search List, LDAP Server Address, WPAD Proxy URL, Netbios
Name Server and Netbios Node Type. My DHCPv6 client requests DNS Server
address and Domain Search List.
You will notice that it doesn't ask for an NTP option, even though it uses NTP.
This is because asking for an NTP option will generate support calls. It
doesn't ask for a printer address. This is because although DHCPv4 provides a
way to deliver printer addresses, nobody uses it. Bonjour is easier and more
convenient, and generates fewer support calls. Even though I have an email
client running, it doesn't ask for IMAP server, SMTP server or POP server,
because that would be ridiculous.
So yes, DHCP is a successful protocol. And yes, application protocol
designers have attempted to use it to configure their protocols. But they
haven't succeeded, in the large, because it's a bad idea. It is not a
successful _applications service discovery_ protocol. It is a successful
_host configuration_ protocol.
I've build small battery powered sensors that use DHCP, DNS and reports
environmental measurements periodically to a server and have a very good
handle on the power usage of these devices. I've done ones that use ethernet
and 802.15.4, (and also ones that don't use DNS or DHCp but run over
satellite links). On those networks, I have concrete measurements that
indicate for that system you are wrong about DNS making a significant
difference to battery life. I realize there might be other applications where
it does make a difference but so I'm having a hard time imagine such an
system. The reason why is simple, the bulk of traffic a sensor sends over a
30 day period is mostly sensor data not DHCP or DNS.
Indeed, in this scenario, power consumed by DNS and DHCP will not be an issue.
On the flip side, for SIP phones we have seen that the level of indirection
form DNS really helps make the operational issues easier.
Yes, and SIP is a lousy example, because it's not generally configured using
DHCP—it's generally configured through a user interface. When it _is_
configured using DHCP, it's done in a constrained environment. The
configuration model used in that environment would be a security disaster on
the open internet.
I think the draft should not say that IPs are preferred over FQDNs. I think
it should say the choice of IP or FQDNs depends on the applications and
factors that should be considered are size, power, extra RTT, if a DNS stack
is available, code size, and so on. But also point out some of the
operational management advantages of DNS.
I agree that these are all good things to mention. However, I think the
document should steer people away from using FQDNs, because if they need to use
FQDNs, they will regardless of what direction the document tries to steer them.
Really we are talking about if you have a parameter in some new protocol X to
control, this BCP is taking the opinion that it knows more about protocol X
than the protocol X WG and that it thinks the parameter should be an IP not
FQDN. I think this is wrong, DHCP should deal with how transport the
configuration parameter that protocol X needs and if that is an IP or FQDN is
probably a choice best left to experts of protocol X. Heck, I'll go a scope
further, I think it is not in charter of the DHC working to determine if IP
or FQDN are best to configure a parameter in some future protocol done by
some other WG.
It is in the charter to recommend best practices for DHCP.
On Oct 10, 2013, at 9:41 AM, Ted Lemon
<Ted(_dot_)Lemon(_at_)nominum(_dot_)com> wrote:
On Oct 9, 2013, at 11:49 PM, Cullen Jennings <fluffy(_at_)iii(_dot_)ca>
wrote:
If this argument were correct, we'd expect to see major O.S. vendors
supporting the NTP option, but we don't—instead, it's something that can
be configured in the UI for situations like the one you describe, and that
otherwise is defaulted to the preconfigured value, which of course can be
updated when the operating system is updated.
Right - I am certainly more focused on the devices that don't have an
administrator that can configure them locally.
This is great, but that's not all devices. And devices of this type often
wind up being very vulnerable to attack precisely because no usable escape
mechanism is offered. DHCP may be your only choice for configuring such a
device, but it's a really lousy choice.
Louse choice? What exactly would you propose that would work better ?
What would be better would be a secure mechanism for configuring them. E.g.,
going to a well-known URL and downloading a configuration signed using a tool
that allows the device to validate the configuration. This is what e.g.
Microsoft Exchange clients do. It works quite well.
Right, and I think I already said that (a) SIP is a bad example of a use
case for DHCP, because it's a node-specific service, not a network-specific
service, and (b) it's probably fine, if you must use DHCP to configure SIP,
to use an FQDN, as I already said several messages back.
Sure, and why does that same argument not hold for configuring similar
services which is what I complained about in the draft.
In general, configuring similar services using DHCP won't work. I'm not
convinced it works for SIP. I'm fairly sure it doesn't work for configuring
NTP.
Look, I am not arguing that one should not us IP address in some cases. I'm
arguing that there are equally good cases where one should use FQDN. I
realize they are not popular with the layer 2/3 folks but they are very
popular with the application layer folks because of the flexibility and easy
of managment they provide.
Can you give me an example of a use case that is _not_ an APPS-area protocol?
BTW, you mentioned that you think NTP and DNS are application layer, but they
are in the INT area for a reason. I mean a protocol that's in the APPS area,
for an equally good reason.
SRV records are normally used for application-layer services, like SIP,
which I don't think should be configured with DHCP. Similarly, would you
use DHCP to configure the address of an HTTP server? :)
This seems to be the heart of it. You don't think this should be used for
application layer services but I don't think that ship sailed long long ago.
The ship sailed long ago, and sank out at sea, yes. I was on it at the
time—like you, I used to think DHCP was for configuring applications. I did
not arrive at my current opinion accidentally.
Once again, please give me an example where the ext ran DNS traffic from the
device forms any relevant percentage of the traffic and/or power usage.
Any time the frequency of reports from the device is similar in frequency to
refreshes required by the DNS TTL expiring.
The refresh on DNS TTL is same as refresh on DHCP lease time
Yes, and if you have to do six DNS queries per DHCP renewal, that's six more
packet exchanges.
DHCP does all the queries for you at the same time and hands you a single
packet with all the information you need to contact all the services offered
by DHCP. This can be expected to result in many fewer packet round trips,
and consequently much less power spent. This is a significant feature;
getting rid of it in order to make life a little more convenient for
operators who do not have to deal with these constraints is a poor value
proposition for the protocol as a whole.
BTW, another example of a constrained device is a network booted device,
where despite the fact that the node itself is quite capable once it's
booted, the boot prom is quite constrained. I think this was a primary
motivation for the choice of address versus FQDN back in DHCPv4 days; I
suspect relevant in fewer cases now, but still relevant in some.
Again, that's a fine argument why BOOTP should use IP, however it is not an
argument about why nothing else should use FQDN
I don't think you said what you meant here. BOOTP is a predecessor to
DHCP—what does that have to do with this conversation?
(I will note, by the way, that you have yet to raise a point that was not
considered and addressed by the working group. I think this discussion is
useful, because it points to clarifications that should be made to the
document, but I don't yet see anything that would suggest to me that the
consensus call went the wrong way.)
Well, why don't you come over to RAI and do a presentation on why we should
not use FQDN in DHCP and see what the consensus is over there. I'm sure the
ADs could arrange some agenda time in the dispatch meeting which is closest
things that RAI has to an area meeting at IETF 88. The consensus of a
particular WG does not necessarily represent the consensus of the IETF.
(a) I can't.
(b) It would be useless. Of course RAI is going to say DHCP should support
configuring application protocols. Why not? It's a cost-free assertion from
your perspective.
(c) This document is saying what the DHC working group recommends. RAI
working groups are free to go against these recommendations. So this document
shouldn't say what RAI recommends. It should say what DHC recommends. If a
working group doesn't want to follow the advice, they don't have to, because
it's just advice, not a requirement.