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

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Jul 2000 14:52:30 -0400

Folks:

The IESG has been discussing this document and some of the wording  in
it has attracted some attention. Specifically:

> 1. Introduction
 
> It is often desirable to provide different levels of service to
> different users of an IP network.  In order for an IP network to
> implement this service differentiation, it needs a way to classify
> users. A simple solution to this is to use source IP addresses for
> classification.  Under this scheme, network administrators first
> configure network devices such as routers to recognize traffic from
> a particular source IP address (or address range) and handle it
> specially to meet the desired level of service. Next, they assign
> the IP addresses to the hosts of the intended users so that the user
> will receive the appropriate level of service.

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.

Then, the security considerations section points out that without
authentication, doing the above is dubious anyway (which leads the
IESG to wonder what this option is really good for). So again, using
this as an example is far from ideal.

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.

I see two ways out:

1) Make it clear what the real relationship between this DHCP option
   and related QOS mechanisms. Note that even making this clear will
   probably still not leave the IESG happy, given the reasons cited
   above. So if this is the approach the WG wants to take, we should
   discuss first.

2) take the example out and use a more appropriate one.

Comments?

Thomas

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 12 Jul 2000 12:58:57 -0700

> possibly out of touch with reality.

Not to defend the text, but there are those of us who believe that RSVP
and DiffServ are also problematic and out of touch with reality.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

---

From: John Schnizlein <[email-masked]>
Date: Wed, 12 Jul 2000 15:47:15 -0400

At 02:52 PM 07/12/2000 -0400, Thomas Narten wrote:
>
>> 1. Introduction
> 
>> ... A simple solution to this is to use source IP addresses for

I don't understand the assertion that this is not done today.
Is it a question of the order in which these steps are performed?
Is it that where queues with different link shares are used for
special traffic, the DiffServ model implies marking at the edge
and current deployments use source or destination addresses?
Does the IESG know that those organizations using custom queuing
to protect SNA/IP traffic have changed to something else?
How much current deployment does there have to be to justify making
this more easily configured through DHCP.

IntServ's model is different; it uses signalling instead of the
simple configuration described in this example. Is this just the
signal or not question in different clothing?

>this as an example is far from ideal.

Yes, classification of traffic based on addresses, especially source
addresses as long as source address verification is not universal in
the routing infrastructure, has authenticity problems. But they are
used despite this in lots of places, including security. Why block
DHCP from what is done by so many others? Because it did not do it
until after the source address authenticity problem was raised? ;-)

We do not have host authentication solved, but experience with how
(much) the proposed option is used could help us decide if/how to
address this problem.

Has the style of Internet development changed from implementing
simple extensions to existing protocols to one in which every
example has to be part of a broad model? I didn't get the memo. :-)

John