Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-proxyserver-opt-04.txt

From: [email-masked]
Date: Wed, 13 Jul 2005 15:50:01 -0400

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		: DHCP Option for Proxy Server Configuration
	Author(s)	: S. Balasubramanian, et al.
	Filename	: draft-ietf-dhc-proxyserver-opt-04.txt
	Pages		: 10
	Date		: 2005-7-13
	
This document defines a new Dynamic Host Configuration Protocol
   (DHCP) option, which can be used to configure Proxy Servers in
   TCP/IP for standard protocols like HTTP, FTP, NNTP, SOCKS, SNMP,
   SLL and etc. Proxy Servers provide controlled and efficient access
   to the Internet, include access control mechanisms for different
   types of user requests and cache frequently accessed information
   (Web pages and possibly files that might have been downloaded
   using FTP and other protocols).

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-proxyserver-opt-04.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-proxyserver-opt-04.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.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 20 Jul 2005 10:40:02 -0700

> 	Filename	: draft-ietf-dhc-proxyserver-opt-04.txt

First, exploring this space is a good thing, and thank you for writing
this draft.  I hope more people are encouraged to think about this
problem.  I know what you're about to read makes it look like I have
nothing good to say about it, but I'm really glad someone is trying
solutions on for size here, becuase we need a standard option for
this.

What to do when the flag is "-" is really not clearly defined, and I
don't like what I'm imagining.

First, excluding destination (by this I assume in the http case you
mean URLs) by the IP address of the target is not handy.  HTTP
clients do not do dns resolutions on their URLs before sending them
to proxies today.  If they did, what should they do if the answer has
more than one A record?

Second, excluding destination IPs by /32s is asking for insanity.  At
a bare minimum, you need CIDR format.

Third, it assumes an 'allow all, exclude some' mentality, when in fact
the orthogonal case is just as frequent - where you want clients to use
a proxy specifically for one namespace.  What does a server do in this
case?  Specify all 2^32-1 IP addresses to exclude?

Finally, I'm having trouble justifying the flags field at all.
"Access lists" is too difficult a problem to solve that easily.  The
"#" flag seems gratuitous, and useless.  What happens when a DHCP server
doesn't know if the proxy requires authentication?  Do we expect clients
to prefer proxies that don't require authentication?

I think the examples ascii art should be reformed to clearly indicate
bit widths.  Reading this, I continually got the misimpression that
'protocol' fields were 1-byte fields.

I also think they should indicate the worst case scenario - from the
RDF examples, it seems you are required to make sure protocol entries
(hard to call them sub-options since they use 2-byte 'option codes')
terminate within the current DHCP level option.

Making the first RDF entry less than 255 bytes long is essentially going
out of your way - this is extra work for that layer of processing.  So
the example makes it appear that you must go out of your way in that
sense.

So I think the example option entries should indicate this 'not as pretty'
case, to avoid suggesting it can't happen; where the first RDF entry is
of length 255, and its data spans the two DHCP-level options.

If that makes any sense at all.  Sorry, it's hard to put this into words
for me for some reason.  Probably not enough caffeine this morning.

On that subject, so long as you are defining a different "sub option"
means, these two-byte protocol codes, and fully expect there to be some
protocols (RDF) that have lengths exceeding 255, I suggest you make the
length fields 2-bytes.

The extra overhead in the proxy protocol sections is minimal, the
savings on combining these RDF fields is maximal.

Of course this assumes you will continue to expect to have RDF fields
exceeding 255 bytes, which I think is a bad move.  It would be better
to just refer to the RDF data with a URI and ask the client to evaluate
it.  400+ bytes of payload is painful.

On the subject of 'concatenating protocols', it's clear to me from
the RDF examples that you expect multiple entries of the same protocol
to be concatenated before being processed.  But:

   In cases where it makes sense to specify more than one proxy server
   for a given protocol, these proxy servers MUST be specified as
   additional IP addresses and ports within the same entry.  The list is
   ordered by precedence, with the most preferred proxy server appearing
   first in the list, and the least preferred proxy server appearing last
   in the list. The DHCP client SHOULD honor this ordering.

   More than one Proxy Server Configuration Entries MAY be specified in
   the option.  In that case, the list is ordered by precedence, with
   the most preferred proxy server appearing first in the list, and the
   least preferred proxy server appearing last in the list. The DHCP
   client SHOULD honor this ordering.

So for RDF we concanate like we do all other DHCP options, something
our dhcp servers should be good at by now.  But for all others we have
to understand magic.  In particular:

1) You have to process non-RDF protocols individually, without
	concatenating.

2) You have to understand that only the last two fields of the non-RDF
	options will repeat (the 'flags' entry exists exactly once for
	every non-RDF protocol).

3) What does a server do when the remaining space in the option
	is less than will contain a single non-RDF entry?

It would be better if you simply allowed multiple entries of the same
protocol to be concatenated, and to expect a full protocol entry for
each proxy (that is, flags, address, port).  It would be even better
if the examples included this case.

Now that I think about it, there's also no clear language about RDF
being or not being null-terminated.  Since it is delimited by length,
it probably should not be terminated, but that's up to you.

Comparing and contrasting with the WPAD option...

On a design level, I'd have to say WPAD is a better approach.  It's
a fuller implementation - the language to describe proxy policy is
javascript.  As much as we like to hate javascript, it being a
fully-formed language makes this a very powerful tool for a sysadmin.
Tricks include confining portions of the DNS namespace (via one-way
hashes similar to DHCP LBA) to one of a variety of caches, which improves
locality of reference and means you don't have to enter into alter-protocol
tricks (ICP, HTCP) to share object databases.

To actually expect to replace the widespread (although unfortunate)
use of WPAD, you will have to match its feature set.

That might be as simple as grandfathering in WPAD as an option similarly
to RDF.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Michael Alexander" <[email-masked]>
Date: Wed, 20 Jul 2005 20:22:19 +0200

>From a previous message on it:
> microsoft has implemented this in ie as a dhcp informmessage through option number 252. Are there no security concerns at the bank when sending _code to be interpreted by javascript on the client??

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 20 Jul 2005 17:05:45 -0700

> > microsoft has implemented this in ie as a dhcp informmessage through option number 252. Are there no security concerns at the bank when sending _code to be interpreted by javascript on the client…

Indeed!

Although from what I've been told it's not IE that sends INFORMs, it's
something that identifies itself to apache via the remote-agent header
as "Industry Updater" which I take to mean "automatic updates."

Which is scarier?

Anyway.

A group of smart folks like us should be able to come up with an
alternative that is not a programming language, is not open to
interpretation, and provides the same or similar knobs while still
having a security considerations section that does not make us blush.

I'm sorry to the authors, I cherish their effort, but I don't think this
draft qualifies.

So, anyone got any better ideas?