Subject: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt

From: [email-masked]
Date: Tue, 22 Aug 2000 13:15:50 +0100

I have updated the User Class draft to take into account IESG comments
as previously agreed on this mailing list (changed parts are the
introduction and the security section).
Thomas: can this ID be considered again by the IESG?

Jerome

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 22 August 2000 12:07
To: DHCPv4 discussion list
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-dhc-userclass-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Dynamic Host Configuration Working Group of
the IETF.

	Title		: The User Class Option for DHCP
	Author(s)	: G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri,
                          A. Demirtjis, B. Beser, J. Privat
	Filename	: draft-ietf-dhc-userclass-10.txt
	Pages		: 5
	Date		: 21-Aug-00
	
This option is used by a DHCP client to optionally identify the type
or category of user or applications it represents.
The information contained in this option is an opaque field that
represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.
This option should be configurable by a user.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-10.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-userclass-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-userclass-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Tue, 22 Aug 2000 13:19:07 +0100

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Aug 2000 11:20:23 -0400

> Thomas: can this ID be considered again by the IESG?

Yes, and thanks for the update.  Looking at the changes, I note a
couple of things that may well provoke additional discussion within
the IESG:

> Abstract

This last sentence again suggests that the address a DHCP server gives
out may depend on the provided user class.

> 4. User Class option
>    A DHCP server uses the User Class option to choose the address pool
>    it allocates an address from and/or to select any other
>    configuration option.

And again here.

While I don't think this document should prohibit doing the above,
suggesting that this be done also requires having more text discussing
the issues of doing so (this lack of discussion of the related issues
is one of the issues the IESG had with the previous ID). For example,
if you are going to tie QOS policy to specific addresses, there needs
to be some sort of coordination between DHCP and the routers. This
should be discussed somewhere. Also, since QOS has tangible value to
end users, suitable protections are needed to ensure proper
authentication. This should be discussed in more detail in the
security considerations section.

Note that in the case of giving out the "wrong" set of printers
addresses to a client that uses the wrong user class identifier, there
don't appear to be any serious implications. But if you give out the
wrong address, the issues would appear to be quite different.

Thomasp

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Aug 2000 09:30:05 -0700

> out may depend on the provided user class.

Maybe I'm being a space cadet here, but why is this a problem?   The
IP address the server gives out also depends on the DHCP Requested
Address option in some cases!   It's perfectly reasonable for the
client to request things, and what the server does depends on policy.
What is it about this that needs to be fixed?

Maybe the thing we want is to say that the client can "request"
variations in how it is treated based on the user class option, and
that whether or not the server honors these requests, and how, is a
decision that should be left up to the server administrator.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Aug 2000 12:54:34 -0400

> Address option in some cases!

Hmm. What is the purpose of that option? Without knowing the history,
I would think that option is to tell the server, "hey I was using
address X before, if its OK with you, I'd like to get it again". Or
something like that.

The general issue is that clients shouldn't care what addresses they
get. I.e., any address should work. Anytime the DHCP server uses
something like the client ID to influence what address is given out,
the implication is that different addresses are used in different ways
(e.g., have different QOS, can punch through firewalls, are in access
control lists for services, etc.) But now the DHCP server needs to be
much more tightly coupled with other parts of the infrastructure
(e.g., routers, firewalls, etc.) The current (and previous ID) says
absolutely nothing about this bigger issue.

What some of the IESG objected to was the implication that the ID
suggested using the client ID to assign addresses that had special
characteristics associated with it *without* discussing in a fair
amount of detail the implication of all this. For example, if a site
was using diffserv, how do the packets from address X get mapped into
special diffserv PHBs?

> It's perfectly reasonable for the client to request things, and what
> the server does depends on policy.  What is it about this that needs
> to be fixed?

This isn't the issue. Its the implication on other parts of the
infrastructure beyound DHCP that are implied by having different
classes of addresses a DHCP server is handing out.

> decision that should be left up to the server administrator.

If I understand "how it is treated" to mean that some clients get
different service than others, then we heading in the problematical
direction. It is not DHCP's job to regulate what kind of service a
client gets. Its DHCP's job just to configure the client with necessary
parameters.

Hope this helps clarify things a bit more. 

Thomas

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 22 Aug 2000 10:00:50 -0700

> From:  Ted Lemon
> Sent: Tuesday, August 22, 2000 9:30 AM
>
[Jerome Privat]
> > >    configuration parameters.

[Thomas Narten]
> > out may depend on the provided user class.
[Ted Lemon]
> decision that should be left up to the server administrator.

...Agreed!  Thomas:  I don't think I'm missing the point here, but am open
to corrections if I am -- the entire purpose of such options as the Vendor
Class Identifier and User Class Identifier is to provide the server with
additional information that the server may use to determine (1) which IP
address to offer the client, and (2) which option values are returned in the
offer.

So, where is the problem with the wording in draft 10?

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Aug 2000 10:42:49 -0700

> address X before, if its OK with you, I'd like to get it again". Or

Yup.   But it's an unsubstantiated claim, and typically the DHCP
server doesn't check it.   As long as the DHCP server has proper
access control checks, this isn't a problem.

> absolutely nothing about this bigger issue.

Hm.   The example that I gave when I wrote up the User Class option in
the DHCP Handbook (I think we deleted this because the option had been
delayed (!)) was that you could configure clients to say whether or
not they were in a certain department.

For example, say you have a sales department, an engineering
department, and an accounting department.  These departments mostly
exchange traffic with each other.  You have all three departments on
one wire, but each has a different IP subnet.  Each department has its
own printers, name servers, and so on.  This is all handled with smart
switches, so performance isn't an issue - as the network
administrator, you don't want to have to constantly be switching wires
around to keep one department on one subnet and another on another as
people move around.

There is no security issue here - it's not that sales isn't *allowed*
on engineering's net - in fact, there is really only one net, with
three virtual subnets that are seperated only by smart switches, so it
would be trivial to get on the wrong net without any interaction with
the DHCP server at all.

It's just more convenient if everybody gets on the net they're
supposed to be on.  In this case, there is no QoS issue - it's simply
a matter of convenience and consistency.  This is not to say that
nobody has ever talked about QoS, but this isn't why I wanted the
option, and I don't think it's why most people want the option.

The fact is that *any* option that uniquely identifies a client or can
be used to classify a client can also be used to set up a completely
insecure ad-hoc QoS system.  I know, because I have customers doing it
now, e.g. with the circuit ID sent back in the relay agent information
option.   That doesn't mean the circuit ID suboption is designed to be
used for determining QoS, and it certainly doesn't mean that it
*should* be used that way, or that that is its best use.

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 22 Aug 2000 12:01:14 -0700

> From:  Thomas Narten
> Sent: Tuesday, August 22, 2000 9:55 AM
>
[Thomas Narten]
> absolutely nothing about this bigger issue.
...true, the draft doesn't say anything at all about that, but we've been
doing things like that for years in commercial use:  giving clients an IP
address from a specific pool based on their user characteristics, but
without a class identifier to guide us, using what was available, usually
the source subnet.

To pretend that administrators and server implementors have never done this
before and that unless it is discussed in a larger context this draft is
somehow suspect is being pedantic, and completely misses the point that as
networks become more complex, policy-based management rises in importance.
In order to build policy mechanisms it is essential that administrators and
implementors have as many bits of information as possible to enable
intelligent policy decisions.

[Thomas Narten]
> amount of detail the implication of all this.
>
...let's extend this argument a bit, stretching perhaps, to see where it
might lead:  if the DHCP server can't use every bit of information supplied
to it by a client, or learned somehow from the environment or configuration
data, to select an IP address to offer the client because that MIGHT overlap
with other protocols such as differentiated services, policy management, or
configuration using SNMP, then the IESG is effectively saying that local
administrators CANNOT use DHCP to apply locally-determined policies to their
own client population, but MUST wait for the jihad between the warring camps
to end, the dust settle, and the winner to arise?  I'm sorry, Thomas, but
that is not reasonable.

This really isn't an attempt to carve out a piece of the other WGs'
charters, but a very practical way to differentiate among differing classes
into which clients may be classified.  If we can't use User Class Identifier
to influence the server's choice of parameters to offer a client, why don't
we also strike out Vendor Class Identifier?  By this argument against User
Classes, ANY parameter that MIGHT reflect a differentiation of service
should be prohibited -- I'm thinking Default WWW Server and similar options,
which certainly provide administrators a way to give different groups of
their users different levels of service for web browsing and such.

[Ted Lemon]
[Thomas Narten]
> classes of addresses a DHCP server is handing out.
...Jeez!  That's always been true, even if we've never said it out loud
before.  I can influence apparent response time to a client simply by giving
them a "distant" and slow name server -- a selection based on any data
available to me when the client requests an address lease.  Or, instead of
giving someone a gateway address through a high-speed router, I could point
them to one running on a 33 Mhz 80486.

[Ted Lemon]
[Thomas Narten]
> client gets. Its DHCP's job just to configure the client with necessary
...If "necessary" were the complete criteria, I'd venture that at least half
of the DHCP options would not exist.  "Useful" has always been a better
criteria, and the current state of the RFCs reflects much give and take,
leaving us with a much richer set of options, many of which I suspect are
NEVER used at all.

It is useful to an administrator to be able to selectively assign networking
parameters (IP address, gateways, name servers, etc.) based upon
characteristics of their client population.  If that were not the case, then
why should we ever have allowed options like NFS parameters, which are not
necessary to establish networking, but emininently useful, to be defined?

The IESG can demand specific wording, and even insist that no variation in
offered configuration parameters is permitted unless differentiated services
is implemented (for example), but I doubt that would change any existing
server implementation, making such a position irrelevant.

--Barr

---

From: "Monika (Maria) Dorough" <[email-masked]>
Date: Tue, 22 Aug 2000 17:10:00 -0700

Someone pleeaaze tell me how to get off this listserve!!!!!