Subject: RE: draft-ietf-dhc-userclass-08.txt

From: Nathan Lane <[email-masked]>
Date: Wed, 12 Jul 2000 14:52:10 -0500

> The issue is that this isn't done today, and is not where QOS (ala
> diffserv) is heading. RSVP also has a different model. Finally, it has
> been stated that the above is not a reflection of real deployments
> today. So, the motivational introductory text is problematic and
> possibly out of touch with reality.
> 
	When it comes right down to it, in networks of today this is exactly
how it ends up being done.  While it may not be QoS in the IETF sense, it is
required to simplify the management of such things as access lists and
firewall rules.  In the real world, the business needs most often preceed
the standardized solutions.  Even the standardized solutions often require
the layering of significant extra software and hardware that increases
complexity without necessarily increasing level of service to the end user.

	We are doing exactly what is described above as a mechanism to allow
certain groups of users different access to the Internet.  Firewalls are
mostly still at the point where they cannot even understand DNS reverse
lookups, let alone more sophisticated methods like mapping an IP address to
an actual username.

> My guess (which may be wrong) is that this is not actually what the
> primary usage of this option is intended for. I thought it was more
> for configuring all the folks in the accounting department to use a
> different printer than the folks in marketing.
> 
	My use of this option would be a combination of the first example
and the above example.  While I'd really like to see the world where every
intermediate device "knew" diffserv and RSVP, it's just not happening as
rapidly as we'd like to see.

	I think it is a valid example.  If we throw out the sections on it
assigning clients to specific address pools based on user-class, most of the
draft is gone according to my recent read of it.  A valid example, but
perhaps not the right example for strong consensus building.

	Any site that has a need for this option should also have an
acceptable security infrastructure for their own needs.  Maybe not
academically perfect, but acceptable for business use.

	Nathan Lane
	Diana Lane

**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************

---

From: [email-masked]
Date: Fri, 14 Jul 2000 09:22:05 -0700

>It is required to simplify the management of such things as access lists
and
>firewall rules.

If that's the intent, there are a few problems:

a. DHCP isn't an access control mechanism, even with authenticated DHCP;
   the user can choose their own static address and thereby get around
   any rules you impose.
b. Authenticated DHCP presumes that the identity is asserted in the
   client identifier option, not the userclass option. Remember that the
   key for authenticated DHCP is a function of the master key and the
   client identifer. Therefore the user can claim any userclass they
   want unless the DHCP server intends to verify the userclass
   assignment based on the client identifier.