Subject: [dhcwg] What sorts of services does DHCP configure?

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Oct 2013 14:25:35 -0400

During the IESG review of the DHCP Option Guidelines document, a number of issues came up, but the most contentious had to do with the question of exactly what services it makes sense to configure with DHCP.   This is an issue because the use model for one class of such services is quite different from the use model for the other class, and prospective users of DHCP to configure services of the other class therefore disputed the option document's advice on when to use FQDNs.

The dichotomy that I would like us to discuss is between network-specific services and node-specific services.

To illustrate what I mean, consider DNS.   DNS is the same everywhere (at least in principle).   If I ask a question of a DNS server on network A, and ask the same question on network B, I should get an equivalent answer; at the very least, the answer should come from the same data, and should validate with DNSSEC.   So it doesn't matter which DNS resolver I use, and indeed this matches how we use DNS.   So DNS is a network-specific service: the DNS server you use probably should be the one closest to you.

Now, consider IMAP.   If you use IMAP, you probably have one or more IMAP servers.   These servers are fixed in location.   You do not check a different IMAP server when you are at Starbucks than you do when you are at home, or at work.   So IMAP is a node-specific service—your IMAP configuration stays with your laptop or tablet, and does not change as you move from network to network.

If you look at the list of DHCPv4 options, you can find lots of IMAP-like services, and lots of DNS-like services.   I think that the DHCPv4 options for configuring node-specific services are a mistake—they are a throwback to a time when nodes didn't move around, so we weren't aware that we had a problem with the use model for DHCPv4 in configuring things like SMTP and IMAP.

At the same time, during the discussion about the Option Guidelines draft, several people raised the idea of services that are configured via DHCP, even though they are node-specific, because in certain cases that's the only option, and it makes sense to configure them that way in those cases.   For instance, a desktop SIP phone might get its initial SIP configuration over DHCP, and then not use DHCP to get SIP configuration anymore.

I am going to make a claim, and I would like the working group to tell me whether they agree with or disagree with this claim.   My claim is that DHCP doesn't make sense for configuring node-specific services.   There may be edge cases where a node-specific service can be configured using DHCP, but DHCP isn't the right service to be used in this case—it's used in this case because there is no better alternative, not because DHCP is a good alternative.   And while there may be edge cases where configuring a particular node-specific service using DHCP makes sense, there will be many more cases where using DHCP to configure that same service would not only not work, but would probably create serious security vulnerabilities.

Thoughts?

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 14 Oct 2013 21:01:52 +0200

My 0.02€/$

I don't agree, certain node specific services are being set by DHCP and
should continue to be so. Examples are routers and DNS servers.

The system that really knows where in the world your laptop is at this
moment is DHCP and of course to a small degree the router itself, though
it only offers you a prefix and a gateway (in case stateless operation
is allowed). Who else would know where you are and therefore which
server would make sense to use here?

IMAP servers are different as you normally have an account on them and
they are not the same for all users on this network segment, SMTP
servers may be the same.

I agree that there is a dividing line, just not there.

And of course which other service should take the task of telling me
those things? Which other server will know my whereabouts so precisely
that it can hand out those informations?

On 14/10/13 20.25, Ted Lemon wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Oct 2013 15:10:07 -0400

On Oct 14, 2013, at 3:01 PM, Sten Carlsen <[email-masked]> wrote:
> I don't agree, certain node specific services are being set by DHCP and should continue to be so. Examples are routers and DNS servers.

Sten, could you go back and re-read what I wrote, because I said those are network-specific, not node-specific, so if you think I was arguing the opposite, either I expressed myself poorly, or you misread what I said.

DNS and routers are network-specific, not node-specific.   IMAP and SMTP are node-specific, not network-specific.

---

From: Sten Carlsen <[email-masked]>
Date: Tue, 15 Oct 2013 02:23:36 +0200

Another 0.02$/€

I have been thinking a bit longer. I still don't quite agree.

I see it this way:
Whatever information is depending on your location at the time of its
use needs to be handed out by the ONE service that actually knows your
location in the network, the service that actively hands out your address.

Examples:
DNS, resolvers are in most cases restricted to the local users, so you
need the local copy but it will give equivalent answers wherever you are.

IMAP, you have an account, so you need access to the one server that
keeps your data. (simplified a bit).

SIP is also very node specific, but there are two ways to look at this
service:
- a SIP phone that will always connect to the same service, so wherever
you may be, you will always use the same service. Works sort of like a
mobile phone. Example: skype.
- a SIP phone that will connect via the local serivice. Works like
bringing your own phone and plugging it into any outlet and using the
phone service of your host.

I have experienced both ways of operating.

The most common example, though it does not fit the bill, is WIFI. If
you get access, it will do the same wherever you are -> mostly network
specific. OTOH you normally have a subscription so only the paying
customer may access the node -> node specific.

I may think that IF DHCP is the only way to distribute information for
geographical reasons, it should be used. OR "somebody" should suggest a
new set of protocols and servers - including how "it" would get the
information about the client's network location from DHCP.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Oct 2013 22:01:33 -0400

Sten, what I'm trying to get to is whether DHCP is the right solution for these problems in the abstract. If it is the only solution that's available now, it's perfectly understandable for people to use it in ways that don't entirely make sense.   But there has been noise made in the IETF about solving the problem of configuring applications like IMAP and SIP in node-specific rather than network-specific ways, and I'm trying to get the sense of whether working group participants agree that that's a good idea, or really think DHCP is the right way to solve that problem and that no better solution is needed or wanted.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 15 Oct 2013 02:02:38 +0000

Hi, Ted,

I am not sure your definition of node-specific here. For me, if the IMAP configuration has one fixed value within the DHCP server managed domain, it is network-specific and may be suitable for DHCP configuration.

In my eyes, node-specific configuration means different among different node, closed to the node-stateful. DHCP stateful model could support node-specific configuration. However, because DHCP does not support user authentication, it may not be the best choice to do node-specific configuration. I guess AAA server and Radius protocol are better choice over DHCP for node-specific configuration.

For what your called node-specific, I guess it is more suitable to call network-independent configuration because they don't change when the node changes attached networks; or Application-specific configuration for that many examples in my mind are application relevant. My concern for them are two: a) is there any harm to do it through DHCP; b) is there better alternative over DHCP.

Regards,

Sheng

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Ted Lemon
>Sent: Tuesday, October 15, 2013 2:26 AM
>To: [email-masked] WG
>Subject: [dhcwg] What sorts of services does DHCP configure?
>
>During the IESG review of the DHCP Option Guidelines document, a number of
>issues came up, but the most contentious had to do with the question of
>exactly what services it makes sense to configure with DHCP.   This is an
>issue because the use model for one class of such services is quite different
>from the use model for the other class, and prospective users of DHCP to
>configure services of the other class therefore disputed the option
>document's advice on when to use FQDNs.
>
>To illustrate what I mean, consider DNS.   DNS is the same everywhere (at
>least in principle).   If I ask a question of a DNS server on network A, and ask
>the same question on network B, I should get an equivalent answer; at the
>very least, the answer should come from the same data, and should validate
>with DNSSEC.   So it doesn't matter which DNS resolver I use, and indeed
>this matches how we use DNS.   So DNS is a network-specific service: the
>DNS server you use probably should be the one closest to you.
>
>Now, consider IMAP.   If you use IMAP, you probably have one or more
>IMAP servers.   These servers are fixed in location.   You do not check a
>different IMAP server when you are at Starbucks than you do when you are at
>home, or at work.   So IMAP is a node-specific service—your IMAP
>configuration stays with your laptop or tablet, and does not change as you
>move from network to network.
>
>If you look at the list of DHCPv4 options, you can find lots of IMAP-like
>services, and lots of DNS-like services.   I think that the DHCPv4 options for
>configuring node-specific services are a mistake—they are a throwback to a
>time when nodes didn't move around, so we weren't aware that we had a
>problem with the use model for DHCPv4 in configuring things like SMTP and
>IMAP.
>
>At the same time, during the discussion about the Option Guidelines draft,
>several people raised the idea of services that are configured via DHCP, even
>though they are node-specific, because in certain cases that's the only option,
>and it makes sense to configure them that way in those cases.   For instance,
>a desktop SIP phone might get its initial SIP configuration over DHCP, and then
>not use DHCP to get SIP configuration anymore.
>
>I am going to make a claim, and I would like the working group to tell me
>whether they agree with or disagree with this claim.   My claim is that DHCP
>doesn't make sense for configuring node-specific services.   There may be
>edge cases where a node-specific service can be configured using DHCP, but
>DHCP isn't the right service to be used in this case—it's used in this case
>because there is no better alternative, not because DHCP is a good alternative.
>And while there may be edge cases where configuring a particular
>node-specific service using DHCP makes sense, there will be many more cases
>where using DHCP to configure that same service would not only not work,
>but would probably create serious security vulnerabilities.
>
>Thoughts?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Oct 2013 22:08:45 -0400

> I am not sure your definition of node-specific here. For me, if the IMAP configuration has one fixed value within the DHCP server managed domain, it is network-specific and may be suitable for DHCP…

That's a pretty big if.   How would the node know?   How would it securely reject IMAP configurations that would be harmful?

> For what your called node-specific, I guess it is more suitable to call network-independent configuration because they don't change when the node changes attached networks; or Application-specific…

I think network-independent is not a bad idea, although maybe network-location-independent is more clear, since of course all of the things we are talking about are dependent on the network.   I agree with you that (a) and (b) are good questions to ask.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 15 Oct 2013 02:33:10 +0000

>> I am not sure your definition of node-specific here. For me, if the IMAP
>configuration has one fixed value within the DHCP server managed domain, it
>is network-specific and may be suitable for DHCP configuration.
>
>That's a pretty big if.   How would the node know?   How would it securely
>reject IMAP configurations that would be harmful?

I guess I should not use IMAP configuration as the example for the definition of network-specific here. It mis-leaded you. I am not ready to discuss in deep regarding to IMAP configuration, yet. :P The clarification of myself should be: IMAP configuration may be configured through DHCP stateless model. It does not match my understanding of node-specific.

Regarding to your question of how node be able to distinguish a harmful configuration, unless there is another alternative mechanism can provide such function, it should not in the center of our concern.

Regards,

Sheng

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Oct 2013 08:14:50 +0200 (CEST)

On Mon, 14 Oct 2013, Ted Lemon wrote:

> I am going to make a claim, and I would like the working group to tell 
> me whether they agree with or disagree with this claim.  My claim is 
> that DHCP doesn't make sense for configuring node-specific services. 
> There may be edge cases where a node-specific service can be configured 
> using DHCP, but DHCP isn't the right service to be used in this 
> case—it's used in this case because there is no better alternative, not 
> because DHCP is a good alternative.  And while there may be edge cases 
> where configuring a particular node-specific service using DHCP makes 
> sense, there will be many more cases where using DHCP to configure that 
> same service would not only not work, but would probably create serious 
> security vulnerabilities.

I agree. In my view DHCP should be used to bootstrap stuff, give you 
information to be able to communicate on the network and know where to go 
to learn more.

So outgoing non-authenticated SMTP server could go into DHCP, IMAP 
account information should not. SMTP server will change with location, 
IMAP account information does not (just as you say).

So in your SIP phone example case, there should be DHCP options to tell it 
where to go to talk to the configuration system, and additional 
information it might need in order to do this.

The Netconf/YANG guys are working on zeroconf draft in order to do this 
kind of bootstrapping, but I can imagine that there will be opposition to 
this method because people are used to have the DHCP client configure 
resolv.conf or NTP or whatever, and bringing in other methods will be 
uphill struggle because of added complexity. In the long run, I think a 
unified method is probably best though.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Sten Carlsen <[email-masked]>
Date: Tue, 15 Oct 2013 10:39:51 +0200

> Sten, what I'm trying to get to is whether DHCP is the right solution for these problems in the abstract. If it is the only solution that's available now, it's perfectly understandable for people t…
I do see your point, what I try to say is that there is no other system
that knows your location within the network better. So either you use
DHCP to hand out a "configuration server" including maybe parameters or
do configurations it self.

I do see that a different type of service to do all those configurations
looks like a good idea, however it also means that that the management
systems now will have yet another system to manage from the same database.

A question: will there be many networks that only have one of the two
types of server?

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Oct 2013 17:15:18 +0700

Since you're asking a largely philosophical question, you'll get a mostly
philosophical answer from me - which will start from looking at what
we can tell of the protocol now - partly from usage (but that doesn't
help a lot for this purpose, as, as you say, it has all kinds of crud jammed 
in) but also from the more simple aspect of its name...

The Dynamic Host Configuration Protocol ... a protocol for configuring
hosts (dynamically, as in not necessarily with static configuration, but
that part isn't relevant to your question I don't think.)

What is, is "host" - as in "node that is not a router" (though I don't see
any particular reason DHCP couldn't be used to configure routers as well).

Just based upon this, attempting to redefine DHCP as a network configuration
protocol, leaving the node configuration for some unspecified something else
looks like it would be backwards.

Next comment is your concentration on "services" being configured.  I think
I know why that is - because if you allowed other node specific information
to get bundled in with the ones that are a problem for you, then this would
be obvious nonsense - other node specific information that gets configured 
include its address (and OK, that's also network specific) and the hostname
(which isn't, or shouldn't be).   Attempt to tell people that DHCP shouldn't
be configuring hostnames (ever) and I doubt you'd get many supporters.

What DHCP offers is information - it doesn't configure services, it just
provides raw data that something else can use to configure the service.
Sometimes that distinction is important.   As an example, DHCP (on unix
systems) doesn't configure resolv.conf - what it does is get s alist of
DNS back end resolvers and make that data available.  Something else
(true, usually run triggered by the DHCP client's actions) takes that
data and (sometimes) puts it in resolv.conf (on other systems it goes into
a "forwarder" config in named.boot or something included from that).

That said, the examples you picked were both particularly poor choices - SMTP
isn't, as for me at least, I prefer that configured just the way you explain
configuring the DNS resolver, as a local network specific service - I just want
the nearest MTA that will be willing to take my mail and deliver it.
The nearer the better, as it increases the chances that I'll be able to
contact it to hand off the e-mail even in the presence of severe network
disruptions.   Of course, I know that others treat SMTP as kind of an inverse
IMAP, where there needs to be an existing relationship (and security config)
between client and server ...

IMAP on the other hand (or POP if anyone is still using that) is not a good
example of what you're asking for an entirely different reason .. of course,
it may be that this causes you to rephrase your question/opinion in a
different way.

IMAP isn't a node specific service at all, it is a user specific service.
You only view it as a node specific service if you have the impression of
a very tight (almost unbreakable) bond between node and user, that is fairly
common these days.   But consider the case of a shared office notebook,
that anyone picks up (one from the pile) and takes away to use for a few
days, returning it when they're done?   Should the IMAP configuration be
node specific, or user specific?

Since when DHCP normally runs (at least initially) the identity of the
user won't always be known, DHCP at first glance doesn't look to be a good
fit for configuring services that are user specific, and need the user's
credentials to be able to determine the proper response - as distinct from
true node configuration (independent of the user).

But, I know that you're not proposing that all of this stuff go unconfigured,
or that we revert to the bad old days, of users attempting to follow the
configuration manual in conjunction with some configuration information
provideed (via a phone call, on a web page, in e-mail, or even printed)
from whatever network info center the user is supposed to get that particular
information from.  That means that we need some kind of a config protocol.
What's more it needs to be a protocol that works starting with a 100%
unconfigured node - and some information for that node (and/or the node's
user) somewhere in the network.

What is the protocol that allows the node to discover where that information
is to be found going to look like, and is it (really) going to be anything
significantly different from DHCP ?

For (some) shared info, we can adopt the IPv6 model (in fact, we should
probably only really be considering IPv6 - doing much more work on IPv4
is really just painful palliative care for an obviously doomed protocol)
and broadcast (that is, of course, multicast) the config.  That works quite
well when the same info is appropriate for all nodes that will receive the
broadcast (like the DNS resolver and router locations).   What that leaves
for DHCP, or some DHCP like protocol, is the information that is meant to be
unique for each node (hostnames, even IMAP servers ...)

Consider a node that has obtained the user identity information from its
user (which may be simply known at boot time for a node that is tightly
bound to a specific user, or later, after the user has been identified and
authenticated in other cases) then sending those credentials to the DHCP
server in a DHCP request option, and for the DHCP server to then reply with
node and user specific information - which it may have obtained by
consulting with a radius (or other AAA) server and hence supply this
particular user's correct IMAP (and other similar) configuration?

Whether that's the right solution or not I don't know, but I do believe that
whatever solution is eventually adopted, it needs to start with making
node & user specific information available to a 100% unconfigured node,
without any user assistance (some nodes may not even have a mechanism for
to user to assist, even if they were able) and I'm having trouble seeing
how any solution is going to be so dramatically different from DHCP that
simply using DHCP as (at least a part of) the resulting protocol wouldn't
be a sane result.

Consequently, I don't think it is a good idea now to start on the divorce
proceedings between these kinds of config info and DHCP, simply writing it
off as a problem for someone else to solve - and while the way that DHCP
is currently defined (and more importantly in many cases perhaps, configured)
to provide this info may be sub-optimal, we may want to see if we can
find an amicable reconciliation.

kre

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Oct 2013 09:15:14 -0400

> I guess I should not use IMAP configuration as the example for the definition of network-specific here. It mis-leaded you. I am not ready to discuss in deep regarding to IMAP configuration, yet. :P…

I chose IMAP deliberately, because it _is_ something that is a local network service, and that made some sense to configure using DHCP back in the olden days when we rode around in horse-drawn buggies and used computers that didn't fit in our pockets (and hence might roam to different networks).

> Regarding to your question of how node be able to distinguish a harmful configuration, unless there is another alternative mechanism can provide such function, it should not in the center of our co…

To be clear, the question I am asking ought to be answered as if such a mechanism did exist.   People have talked about creating such a mechanism, and I think it's a good idea.   If there were a mechanism for delivering configuration information that ought not to vary as a device moves from network to network, what services would you still want to configure using DHCP?   What services would it no longer make sense to configure using DHCP.

It's important to note that _nobody_ uses DHCP to configure IMAP or POP or SMTP.   You can't buy a device that gets these configurations from DHCP automatically, even though DHCP provides the ability to configure these services.

Why not?   Because it doesn't work.   IMAP and POP are specific to the user.   You set up IMAP and POP manually.   Microsoft actually has a proprietary protocol for configuring Exchange based on your email address.

There are some services where it _sometimes_ works for DHCP to be what configures it.   There are some services where it _obviously_ works for DHCP to configure it.   There are some services where it _never_ makes sense for DHCP to configure it.   This is what I'm getting at.   I'd like to try to get some clarity on how we can predict which services, even if we added a DHCP option to support them, would never be configured by DHCP, which would be configured by DHCP only in restricted cases, and which would almost always be configured by DHCP.

I would also like us to discuss the security implications of configuring these services via DHCP.   E.g., if you configure SMTP via DHCP and start sending mail out the SMTP server you got from DHCP, isn't spam filtering going to cause your mail to bounce?   If you configure SIP using DHCP, aren't you going to wind up exposing yourself to eavesdropping when you use a SIP server without any secure mechanism for determining who operates it?

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 15 Oct 2013 13:41:19 +0000

Hi,

Would it make sense to determine which DHCP options are used today in wild
and reasoning behind them?

I have done a few captures before and noticed that DHCP options vary
between home, Hotel, Hotspot, Airport, etc.

As far as your SIP example below, I see SIP server through DHCP just as a
discovery step. Your SIP client should apply whatever security policies to
accept or not that SIP Server.

Thanks,

Reinaldo

On 10/15/13 6:15 AM, "Ted Lemon" <[email-masked]> wrote:

>> I guess I should not use IMAP configuration as the example for the
>>definition of network-specific here. It mis-leaded you. I am not ready
>>to discuss in deep regarding to IMAP configuration, yet. :P The
>>clarification of myself should be: IMAP configuration may be configured
>>through DHCP stateless model. It does not match my understanding of
>>node-specific.
>
>I chose IMAP deliberately, because it _is_ something that is a local
>network service, and that made some sense to configure using DHCP back in
>the olden days when we rode around in horse-drawn buggies and used
>computers that didn't fit in our pockets (and hence might roam to
>different networks).
>
>> Regarding to your question of how node be able to distinguish a harmful
>>configuration, unless there is another alternative mechanism can provide
>>such function, it should not in the center of our concern.
>
>To be clear, the question I am asking ought to be answered as if such a
>mechanism did exist.   People have talked about creating such a
>mechanism, and I think it's a good idea.   If there were a mechanism for
>delivering configuration information that ought not to vary as a device
>moves from network to network, what services would you still want to
>configure using DHCP?   What services would it no longer make sense to
>configure using DHCP.
>
>It's important to note that _nobody_ uses DHCP to configure IMAP or POP
>or SMTP.   You can't buy a device that gets these configurations from
>DHCP automatically, even though DHCP provides the ability to configure
>these services.
>
>Why not?   Because it doesn't work.   IMAP and POP are specific to the
>user.   You set up IMAP and POP manually.   Microsoft actually has a
>proprietary protocol for configuring Exchange based on your email address.
>
>There are some services where it _sometimes_ works for DHCP to be what
>configures it.   There are some services where it _obviously_ works for
>DHCP to configure it.   There are some services where it _never_ makes
>sense for DHCP to configure it.   This is what I'm getting at.   I'd like
>to try to get some clarity on how we can predict which services, even if
>we added a DHCP option to support them, would never be configured by
>DHCP, which would be configured by DHCP only in restricted cases, and
>which would almost always be configured by DHCP.
>
>I would also like us to discuss the security implications of configuring
>these services via DHCP.   E.g., if you configure SMTP via DHCP and start
>sending mail out the SMTP server you got from DHCP, isn't spam filtering
>going to cause your mail to bounce?   If you configure SIP using DHCP,
>aren't you going to wind up exposing yourself to eavesdropping when you
>use a SIP server without any secure mechanism for determining who
>operates it?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Oct 2013 10:14:13 -0400

> between home, Hotel, Hotspot, Airport, etc.

It can't hurt to ask this question, but I'm not convinced that it's necessary.   DHCP clients don't use options they don't request, so it doesn't matter if the server sends them.   So it's probably not necessary to survey DHCP servers—just survey DHCP clients and see what options they request.

> accept or not that SIP Server.

Right, but going a little farther into your example, this only works for clients that (a) request the SIP option and (b) have some way of validating the response they get back.   So we can have a very clear discussion about this security model, and also possibly ask whether existing clients actually do this, and whether this is a good idea, or just the best we could do with what services are available.

And then this question can be asked about lots of other services as well.  E.g., does it make sense to configure NTP this way, given that NTP provides replay protection for security protocols (that's a complicated question)?   Does it make sense to configure SMTP this way, given that SMTP servers are no longer really interchangeable as they were in the early days of the Internet?   POP?   IMAP?   Etc.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 15 Oct 2013 14:44:58 +0000

On 10/15/13 7:14 AM, "Ted Lemon" <[email-masked]> wrote:

>It can't hurt to ask this question, but I'm not convinced that it's
>necessary.   DHCP clients don't use options they don't request, so it
>doesn't matter if the server sends them.   So it's probably not necessary
>to survey DHCP servers‹just survey DHCP clients and see what options they
>request.

Right, DHCP clients.

certain OSs allows applications to ask for certain DHCP options.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363298%28v=vs.85%
29.aspx

>Right, but going a little farther into your example, this only works for
>clients that 

"Clients" here can be an application as above, not necessarily a DHCP
client that triggers everything.

>(a) request the SIP option and (b) have some way of validating the
>response they get back.   So we can have a very clear discussion about
>this security model, and also possibly ask whether existing clients
>actually do this, and whether this is a good idea, or just the best we
>could do with what services are available.
>
>And then this question can be asked about lots of other services as well.
> E.g., does it make sense to configure NTP this way, given that NTP
>provides replay protection for security protocols (that's a complicated
>question)?   Does it make sense to configure SMTP this way, given that
>SMTP servers are no longer really interchangeable as they were in the
>early days of the Internet?   POP?   IMAP?   Etc.
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Oct 2013 11:25:50 -0400

> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363298%28v=vs.85%

Yup.   And in that case, we should see the option on the DHCP parameter request list.   It would be interesting to know what clients rely on this behavior.

---

From: Sten Carlsen <[email-masked]>
Date: Tue, 15 Oct 2013 17:38:19 +0200

You do have a point in bringing the user into this.

I suggest to focus on looking at services and servers in three groups:
- location agnostic, DNS is an example.
- location specific, router is an example
- user dependent, IMAP is an example

I think only those that are not user specific should be provided by DHCP.

Next question is of course whether hosts actually request and use these.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Oct 2013 16:50:05 -0400

On Oct 15, 2013, at 4:39 AM, Sten Carlsen <[email-masked]> wrote:
> I do see your point, what I try to say is that there is no other system that knows your location within the network better. So either you use DHCP to hand out a "configuration server" including maybe parameters or do configurations it self.
> 
> I do see that a different type of service to do all those configurations looks like a good idea, however it also means that that the management systems now will have yet another system to manage from the same database.
> 
> A question: will there be many networks that only have one of the two types of server?

Hm, I think you've hit on another question.   I'm not sure it's central, but it's worth thinking about.   The SMTP server doesn't vary depending on where in the local network topology the host is connected.   The DNS server needn't either.   The router does, obviously.   Can you think of other examples?

BTW, DNS servers frequently are set up with maps of the network in the way that you describe, and indeed one of the arguments against the advice given on FQDNs in the Option Guidelines document is that people might want to do that, and if the DHCP server does the DNS lookup, it won't work.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 15 Oct 2013 21:07:37 +0000

Foreword, I'm not sure this is done through DHCP or which role it plays in
determining user location.

In some enterprise environments the mail server you connect (Exchange or
IMAP) vary depending on your location. Same for SIP Servers, etc.  You
want users to connect to the closest server.

On 10/15/13 1:50 PM, "Ted Lemon" <[email-masked]> wrote:

>Hm, I think you've hit on another question.   I'm not sure it's central,
>but it's worth thinking about.   The SMTP server doesn't vary depending
>on where in the local network topology the host is connected.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Oct 2013 17:22:37 -0400

> want users to connect to the closest server.

Can you give me any example where DHCP is the right way to solve the problem as you have stated it?   Particularly in an enterprise environment, I am _highly_ skeptical that there is ever a case where it makes sense to send a user to different Exchange servers as they move around the company.

SIP is a little more believable, in that I really wish my current SIP<->POTS provider allowed me to register with the closest SIP server rather than always being bound to the SIP server closest to my home, but I don't see how DHCP can help me to solve this problem, since the SIP server I would need to register with is based on my relationship to my SIP provider, not to whoever happens to have an open WiFi for me to use at the moment.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 15 Oct 2013 22:01:26 +0000

On 10/15/13 2:22 PM, "Ted Lemon" <[email-masked]> wrote:

>Can you give me any example where DHCP is the right way to solve the
>problem as you have stated it?

Right way? I can not. It might be one way, and if not DHCP something else
needs to be on its place.

>Particularly in an enterprise environment, I am _highly_ skeptical that
>there is ever a case where it makes sense to send a user to different
>Exchange servers as they move around the company.

By move around I mean when I'm in Japan my iPhone connects to closest Push
Server. 

>
>SIP is a little more believable, in that I really wish my current
>SIP<->POTS provider allowed me to register with the closest SIP server
>rather than always being bound to the SIP server closest to my home, but
>I don't see how DHCP can help me to solve this problem, since the SIP
>server I would need to register with is based on my relationship to my
>SIP provider, not to whoever happens to have an open WiFi for me to use
>at the moment.

There are several SIP Servers and relays inside some companies.

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 16 Oct 2013 00:06:24 +0200

> Can you give me any example where DHCP is the right way to solve the problem as you have stated it?   Particularly in an enterprise environment, I am _highly_ skeptical that there is ever a case wh…
Actually that is what happened in Nokia, it was not in general the DHCP
that made it happen but yes, there is a good case here. Think that I
normally live in Copenhagen but next day I might be in Beijing or San
Diego, you really want to use the closer server and in some cases there
are strict rules, maybe even laws about it (not sure which). For
Exchange, the point is obviously that your mail and calendar comes from
the same repository wherever you are but outgoing mail and other
services may be more locally anchored.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 16 Oct 2013 00:12:11 +0200

> Hm, I think you've hit on another question.   I'm not sure it's central, but it's worth thinking about.   The SMTP server doesn't vary depending on where in the local network topology the host is c…
Depending if the organisation is local or global, I can think of the
selection of printers. It is rather impractical to print on the homely
printer when you are abroad. I have not seen this solved in a really
good way yet but I have seen the problems. Normally I don't print much
but some items must be on paper and finding a printer usually takes forever.
At least show me the local printer portal that knows about all local
printers.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Oct 2013 18:18:12 -0400

On Oct 15, 2013, at 6:06 PM, Sten Carlsen <[email-masked]> wrote:
> Actually that is what happened in Nokia, it was not in general the DHCP that made it happen but yes, there is a good case here. Think that I normally live in Copenhagen but next day I might be in Beijing or San Diego, you really want to use the closer server and in some cases there are strict rules, maybe even laws about it (not sure which). For Exchange, the point is obviously that your mail and calendar comes from the same repository wherever you are but outgoing mail and other services may be more locally anchored.

Hm, so Outlook somehow got this information out of DHCP?   This sounds like a really cool new attack vector.

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 16 Oct 2013 00:24:27 +0200

> Hm, so Outlook somehow got this information out of DHCP?   This sounds like a really cool new attack vector.
No, I don't think DHCP was involved and it did not work as painless as
it should have. I was thinking that DHCP might provide an address to a
portal or such that might do the actual work. A bit like the "next
server" for TFTP.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Oct 2013 18:43:12 -0400

On Oct 15, 2013, at 6:24 PM, Sten Carlsen <[email-masked]> wrote:
> No, I don't think DHCP was involved and it did not work as painless as it should have. I was thinking that DHCP might provide an address to a portal or such that might do the actual work. A bit like the "next server" for TFTP.

Okay, so just to be clear here, I'm not looking for new applications for DHCP.   I'm asking people to tell me if they disagree with my theory that services of this type (a) can't be generally configured by DHCP and (b) aren't typically configured by DHCP at the present time.   Yes, of course you can cobble together some hack using DHCP.

The question is (a) is it _ever_ a good idea, (b) is it safe to enable this behavior by default on all nodes, and (c) if it's not safe, is the behavior in any sense useful?

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 16 Oct 2013 00:59:45 +0200

On 16/10/13 00.43, Ted Lemon wrote:
> Okay, so just to be clear here, I'm not looking for new applications for DHCP.
Right, that is fine.
>    I'm asking people to tell me if they disagree with my theory that services of this type (a) can't be generally configured by DHCP and (b) aren't typically configured by DHCP at the present time.   Yes, of course you can cobble together some hack using DHCP.
>
I tend to look at this from the opposite side, what are the services
that need to be configured and infomation that needs to be delivered?
And as a consequence what are the tools?
What is in the toolbox now and what is missing? Some of the missing
tools are leading to ugly hacks now.
The answer might not be DHCP, but then what is it?

I am still trying to learn more.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 15 Oct 2013 23:03:09 +0000

Agree with  Sten.

From: Sten Carlsen <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 15, 2013 3:59 PM
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Cc: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] What sorts of services does DHCP configure?

On Oct 15, 2013, at 6:24 PM, Sten Carlsen <[email-masked]><mailto:[email-masked]> wrote:

Right, that is fine.

I tend to look at this from the opposite side, what are the services that need to be configured and infomation that needs to be delivered? And as a consequence what are the tools?
What is in the toolbox now and what is missing? Some of the missing tools are leading to ugly hacks now.
The answer might not be DHCP, but then what is it?

--
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Oct 2013 11:30:08 -0400

> The answer might not be DHCP, but then what is it?

I don't think the missing tools are causing us to do ugly hacks.   I think that the problems I am talking about are actually being handled perfectly well.   E.g., SMTP is generally configured manually by the end user, and there is no way to make this better using DHCP, which is why it hasn't been done.   NTP is generally hard-coded as an FQDN into the operating system, but overridable by the end-user.

Although there is an NTP option for DHCP, and it is implemented in some cases, it is not widely used, for reasons that seem obvious to me: NTP is required for replay detection, and so trusting the DHCP server to tell you what your NTP server is isn't secure.   There is actually a standard in the RFC editor queue that makes support for the NTP option mandatory in home routers, which I expect will happen, and I expect that roughly zero devices will actually request this option on a home network.   It's possible that IoT devices will, but I'll believe it when I see it.