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

From: [email-masked]
Date: Mon, 10 Jul 2006 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-05.txt
	Pages		: 8
	Date		: 2006-7-10
	
This document defines a new Dynamic Host Configuration Protocol 
DHCP) option, which can be used to configure the TCP/IP host's  
Proxy Server configuration for standard protocols like HTTP,FTP, 
NNTP,SOCKS, Gopher, SLL and etc.  Proxy Server provides controlled 
and efficient access to the Internet by access control mechanism  
for different types of user requests and caching 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-05.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-05.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-05.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: Andre Kostur <[email-masked]>
Date: Mon, 10 Jul 2006 13:11:46 -0700

What benefit does the MD5 hash give?

According to the draft, this is an MD5 hash of the PAC URI.   If a 
man-in-the-middle desired to change the PAC URI, it could just as easily 
rewrite the MD5 hash too, negating whatever "security" it may have provided.

Now if this was the MD5 hash of the PAC file that is going to be 
obtained via the specified URI, that may provide some benefit against 
someone replacing the PAC file.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Michael Alexander <[email-masked]>
Date: Tue, 11 Jul 2006 06:07:25 +0900

checksum-type integrity of the uri - not to protect against (mim)  
attacks

On 11.07.2006, at 05:11, Andre Kostur wrote:

> man-in-the-middle desired to change the PAC URI, it could just as  
> easily rewrite the MD5 hash too, negating whatever "security" it  
> may have provided.
>
> obtained via the specified URI, that may provide some benefit  
> against someone replacing the PAC file.
> <akostur.vcf>

---

From: Andre Kostur <[email-masked]>
Date: Mon, 10 Jul 2006 14:18:51 -0700

Michael Alexander wrote:
> checksum-type integrity of the uri - not to protect against (mim) attacks
>

So why does this option need this extra protection from random 
corruption of the UDP packet?  As opposed to pretty much every other 
option that you can send back to a client?

---

From: Michael Alexander <[email-masked]>
Date: Tue, 11 Jul 2006 15:39:16 +0900

that's why it is optional

On 11.07.2006, at 06:18, Andre Kostur wrote:

> corruption of the UDP packet?  As opposed to pretty much every  
> other option that you can send back to a client?
>

Best Regards,

Dr. Michael Alexander
WU Wien Dept. of Information Systems
[email-masked] / +43.1.31336.4467

---

From: Andre Kostur <[email-masked]>
Date: Tue, 11 Jul 2006 04:12:05 -0700

> that's why it is optional

[re: the MD5 hash sub-option]

But why complicate this option by making it a sub-optioned option for a 
sub-option with arguable benefit?  As previously mentioned, the hash is 
only intended to defend against incidental corruption of the DHCP 
packet.  Why does this option rate an extra defense against this rather 
than some mechanism (unrelated to this draft) which would guard the 
entire DHCP packet from accidental corruption?   Do we (as a WG) intend 
that each new option should be a sub-optioned option, each carrying an 
MD5 hash of its data?
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Michael Alexander <[email-masked]>
Date: Tue, 11 Jul 2006 23:33:04 +0900

you are right, looking at it from the packet level, a hash is better  
and optionally placed there

On 11.07.2006, at 20:12, Andre Kostur wrote:

>> But why complicate this option by making it a sub-optioned option  
>> for a sub-option with arguable benefit?  As previously mentioned,  
>> the hash is only intended to defend against incidental corruption  
>> of the DHCP packet.  Why does this option rate an extra defense  
>> against this rather than some mechanism (unrelated to this draft)  
>> which would guard the entire DHCP packet from accidental  
>> corruption?   Do we (as a WG) intend that each new option should  
>> be a sub-optioned option, each carrying an MD5 hash of its data?
>

Best Regards,

Dr. Michael Alexander

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 17 Jul 2006 12:05:24 -0700

> and optionally placed there

UDP header and data payload checksums should not be construed as
optional.

-- 
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