idnits 2.17.1
draft-ietf-dhc-proxyserver-opt-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1.a on line 18.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 477.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 454.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 461.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 467.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
483), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 40.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
This document is an Internet-Draft and is subject to all provisions of
Section 3 of RFC 3667.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 9
longer pages, the longest (page 10) being 61 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 11 instances of too long lines in the document, the longest
one being 11 characters in excess of 72.
** There are 59 instances of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
The Proxy Server Configuration entries SHOULD not repeat the same
type of proxy entries. The port MUST be a valid TCP/UDP port. If the
length of the Proxy Server Configuration Option exceeds the maximum
permissible within a single option (255 octets), then the option MUST be
represented in the DHCP message as specified in [RFC-3396].
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
More than one RDF type of Proxy Server Configuration Entry MUST not
be sent in this option. This is because, the RDF Meta Data is generally
more than 255 octets and always require more than one option of this type
as per [RFC-3396]. However, more than one proxy server configuration
(FTP, HTTP, SOCKS) can be specified with the same RDF Meta Data as follows
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 2005) is 6945 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC 2119' is mentioned on line 122, but not defined
== Unused Reference: 'RFC-2119' is defined on line 371, but no explicit
reference was found in the text
== Unused Reference: 'RFC-2616' is defined on line 386, but no explicit
reference was found in the text
== Unused Reference: 'RFC-959' is defined on line 390, but no explicit
reference was found in the text
== Unused Reference: 'RFC-1436' is defined on line 393, but no explicit
reference was found in the text
== Unused Reference: 'RFC-977' is defined on line 398, but no explicit
reference was found in the text
== Unused Reference: 'RFC-1928' is defined on line 401, but no explicit
reference was found in the text
== Unused Reference: 'SSL2' is defined on line 404, but no explicit
reference was found in the text
== Unused Reference: 'SSL3' is defined on line 407, but no explicit
reference was found in the text
== Unused Reference: 'RFC-1625' is defined on line 410, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 977
(Obsoleted by RFC 3977)
Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group Senthil K Balasubramanian
2 Internet-Draft Intoto
3 Expires: September 2005 Michael Alexander
4 Gustaf Neumann
5 Wirtschaftsuniversitaet Wien
6 April 2005
8 DHCP Option for Proxy Server Configuration
9 draft-ietf-dhc-proxyserver-opt-03.txt
11 Status of this Memo
13 This document is an Internet-Draft and is subject to all provisions
14 of section 3 of RFC 3667. By submitting this Internet-Draft, each
15 author represents that any applicable patent or other IPR claims of
16 which he or she is aware have been or will be disclosed, and any of
17 which he or she become aware will be disclosed, in accordance with
18 RFC 3668.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as
23 Internet-Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on September 2005.
38 Copyright Notice
40 Copyright (C) The Internet Society (2005). All Rights Reserved.
42 Abstract
44 This document defines a new Dynamic Host Configuration Protocol
45 (DHCP) option, which can be used to configure the TCP/IP host's Proxy
46 Server configuration for standard protocols like HTTP, FTP, NNTP,
47 SOCKS, Gopher, SLL and etc. Proxy Server provides controlled and
48 efficient access to the Internet by access control mechanism for
49 different types of user requests and caching frequently accessed
50 information (Web pages and possibly files that might have been
51 downloaded using FTP and other protocols).
53 1. Terminologies Used
54 DHCP Client: A DHCP [RFC-2131] client is an Internet host that
55 uses DHCP to obtain configuration information such as
56 network address.
58 DHCP Server: A DHCP server [RFC-2131] is an Internet host that
59 returns configuration parameters to DHCP clients.
61 Proxy Server: In a enterprise network that connects to Internet,
62 a proxy server is a server that acts as an intermediary
63 between a workstation user and the Internet so that the
64 enterprise can ensure security, administrative control,
65 and caching service. A Proxy server MAY be associated
66 with or part of a gateway server that separates the
67 enterprise network from the outside network (Usually
68 Internet) and a firewall server that protects the
69 enterprise network from outside intrusion.
71 RDF:A language (Resource Description Framework [RDF-SYN]) for
72 describing properties of web resources.
74 2. Introduction
76 The Dynamic Host Configuration Protocol [RFC-2131] provides a
77 framework for passing configuration information to hosts on a TCP/IP
78 network. This document describes a DHCP configuration option that
79 can be used to inform a DHCP client, the IP addresses of one or more
80 proxy services that are either available to it or that must be used
81 in order to access internet services, for example through a coporate
82 firewall.
84 The following diagram depicts the typical setup providing proxy
85 service to clients on a network that is protected by a firewall.
87 +---------------------------+ +-----------+
88 | | |Remote HTTP|
89 | | HTTP |Server |
90 | +------------+ +-------------+<--->+-----------+
91 | | Clients | |Proxy Server |
92 | | Inside the |<------>| + | FTP +-----------+
93 | | Firewall | |Firewall |<--->|Remote FTP |
94 | +------------+ +-------------+ |Server |
95 | | ^ +-----------+
96 | | |
97 | | | +-----------+
98 +---------------------------+ | NNTP |Remote NNTP|
99 +------------>|Server |
100 +-----------+
102 The primary use of proxies is to allow access to the World Wide Web
103 from within a firewall. A proxy service typically runs on firewall
104 machine. It waits for a request from inside the firewall, forwards
105 the request to the remote server outside the firewall, reads the
106 response and then sends it back to the client. Usually, all the
107 clients use the same proxy within a given network, which helps in
108 efficient caching of documents that are requested by a number of
109 clients. This behavior makes proxies attractive to clients not
110 inside a firewall.
112 A proxy server increases the network security and user productivity
113 by content filtering and controlling both internal and external
114 access to information. Also, it provides several other
115 functionalities that are not discussed here.
117 3. Requirements terminology
119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
121 document are to be interpreted as described in [RFC 2119].
123 4. Proxy Server Configuration Option
125 This document defines a new DHCP Option called the Proxy Server
126 Configuration Option. The format of the Proxy Server configuration
127 option is:
129 Code Len Proxy Server Configuration Entry
130 +-------+------+------+------+------+------+-....-+------+
131 | TBD | N | e1 | e2 | e3 | e4 | | en |
132 +-------+------+------+------+------+------+-....-+------+
134 Code is TBD and will be assigned by IANA according to [RFC-2939].
135 The length N gives the total number of octets in the Proxy Server
136 Configuration entries.
138 The Proxy Server Configuration entry normally consists of a
139 sequence of Protocol Type (p), len (l), flag (f), IP
140 address and port. But it can also be a sequence of Protocol
141 Type (p), Len and RDF[RDF-SYN] metadata.
143 +--+--+--+--+--+--+--+--+--+
144 |p |l | f |IP address|port |
145 +--+--+--+--+--+--+--+--+--+
147 The Protocol(p) is a two octet integer in network byte order,
148 length (l) and flag (f) are one octet each; each IP
149 address is four octets, and each port number is a two-octet
150 integer encoded in network byte order.
152 The protocol type(p) specifies the type of Protocol and MUST be
153 one of the following assigned numbers.
155 +-------------------------------+
156 | protocol | Number |
157 +-------------------------------+
158 | HTTP | 80 |
159 +-------------------------------+
160 | FTP | 21 |
161 +-------------------------------+
162 | NNTP | 119 |
163 +-------------------------------+
164 | Gopher | 70 |
165 +-------------------------------+
166 | SSL | TBD |
167 +-------------------------------+
168 | SOCKS | 1080 |
169 +-------------------------------+
170 | WAIS | 210 |
171 +-------------------------------+
172 | IMAP | 220 |
173 +-------------------------------+
174 | RDF | TBD |
175 +-------------------------------+
177 If the protocol type field is RDF[RDF-SYN], then it MUST be
178 followed by len (length of RDF metadata) and the actual RDF
179 metadata.
181 The length field (l) specifies the length of the Proxy Server
182 Configuration entry. If some new protocol is introduced in the
183 future and if some version of dhcpclient doesn't support, then
184 that particular entry can be ignored and process the following
185 Proxy Server Configuration Entry, if any.
187 The flag field (f) is by default 0. Otherwise, it can either
188 have "-" or "#".
190 If it is "-", then the entry becomes a destination address for
191 exclusion from forwarding to the proxy. If it is "#", then the proxy
192 requires authentication.
194 In cases where it makes sense to specify more than one proxy server
195 for a given protocol, these proxy servers MUST be specified as
196 additional IP addresses and ports within the same entry. The list is
197 ordered by precedence, with the most preferred proxy server appearing
198 first in the list, andthe least preferred proxy server appearing last
199 in the list. The DHCP client SHOULD honor this ordering.
201 More than one Proxy Server Configuration Entries MAY be specified in
202 the option. In that case, the list is ordered by precedence, with
203 the most preferred proxy server appearing first in the list, and the
204 least preferred proxy server appearing last in the list. The DHCP
205 client SHOULD honor this ordering.
207 The format of the Proxy Server Configuration using Metadata type is:
209 p Len RDF Metadata for the Proxy
210 +-------+------+----------------------------------+
211 | RDF | N | RDF |
212 +-------+------+----------------------------------+
214 The RDF payload is freeform RDF metadata for describing proxy
215 properties. The length N gives the number of octets in the RDF
216 metadata field.
218 The following entry specifies the sample format of the RDF Meta
219 data field
221 HTTP proxy:
223
224 ]>
225
227
228 License Gate Proxy
229 John Doe
230 Duke OIT
231 Offsite Campus Resource Access Proxy
232 Service
233 Current Duke faculty, staff, and students
234 2004-06-15
235
236
238 FTP proxy:
240
241 ]>
242
244
245 License Gate FTP Proxy
246 John Doe
247 Duke OIT
248 Offsite Campus Resource Access Proxy
249 Service
250 Current Duke faculty, staff, and students
251 2004-06-15
252
253
255 As such there is no minimum length to specify a proxy using RDF
256 metadata. But the minimum sensible statement would be a literal
257 description of the proxy (License Gate Proxy)
258 giving a total of 418 characters including the overhead.
260 For example, with a description element of 60 characters, an URI of
261 80 characters plus a minimum XML/RDF syntax conformation/namespace
262 declaration of:
264 21 Octets
265 70 Octets ]>
266 64 Octets
268 109 Octets
269 81 Octets ..60 characters..
270 18 Octets
271 10 Octets
273 ,the minimum length would be 418 octes.
275 5. Option Usage
277 The Proxy Server Configuration entries SHOULD not repeat the same
278 type of proxy entries. The port MUST be a valid TCP/UDP port.
279 If the length of the Proxy Server Configuration Option exceeds the
280 maximum permissible within a single option (255 octets), then the
281 option MUST be represented in the DHCP message as specified
282 in [RFC-3396].
284 The following example shows how an RDF version of proxy server
285 configuration entry of 400 octets is represented in the option.
287 Code Len Proto Len
288 +-------+------+------+------+------+------+-....-+------+
289 | TBD | 255 | RDF | 253 | RDF Meta Data.............|
290 +-------+------+------+------+------+------+-....-+------+
291 Code Len Proto Len
292 +-------+------+------+------+------+------+-....-+------+
293 | TBD | 149 | RDF | 147 | RDF Meta Data.............|
294 +-------+------+------+------+------+------+-....-+------+
296 The following example shows how the same RDF version of proxy
297 server configuration entry of 400 octets is represented in the
298 option along with a normal version (p|l|f|IP|port) of proxy
299 server configuration entry.
301 +---+---+----+-+-+-------------+----+---+---+...-+---+-----+
302 |TBD|255|HTTP|7|0|192.168.5.10 |8080|RDF|243| RDF Meta Data|
303 +---+---+----+-+-+-------------+----+---+---+...-+---+-----+
305 +-------+------+------+------+------+------+-....-+------+
306 | TBD | 159 | RDF | 157 | RDF Meta Data.............|
307 +-------+------+------+------+------+------+-....-+------+
309 More than one RDF type of Proxy Server Configuration Entry MUST
310 not be sent in this option. This is because, the RDF Meta Data is
311 generally more than 255 octets and always require more than one
312 option of this type as per [RFC-3396]. However, more than one proxy
313 server configuration (FTP, HTTP, SOCKS) can be specified with the
314 same RDF Meta Data as follows
316 HTTP and FTP Proxy
318
319 ]>
320
322
323 License Gate FTP Proxy
324 John Doe
325 Duke OIT
326 Offsite Campus Resource Access Proxy
327 Service
328 Current Duke faculty, staff, and students
329 2004-06-15
330
331
332 License Gate Proxy
333 John Doe
334 Duke OIT
335 Offsite Campus Resource Access Proxy
336 Service
337 Current Duke faculty, staff, and students
338 2004-06-15
339
340
342 6. Security Considerations
344 The DHCP Options defined here allow an intruder DHCP server to
345 misdirect a client, causing it to access a nonexistent or malicious
346 proxy server. This allows for a denial of service or man-in-the-middle
347 attack. This is a well known property of the DCHP protocol; this option
348 does not create any additional risk of such attacks.
350 DHCP provides an authentication mechanism, as described in [RFC-3118],
351 which may be used if authentication is required.
353 7. IANA Considerations
355 IANA is requested to assign an option code to the Proxy Server
356 Configuration Option and protocol numbers for the SSL and RDF
357 protocol.
359 8. Acknowledgements
361 Thanks to the DHC Working Group for their time and input into the
362 specification. In particular, thanks to (in alphabetical order)
363 Bernie Volz, Ralph Droms, Robert Elz, and Ted Lemon for their
364 thorough review.
366 9. Normative References
368 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
369 March 1997.
371 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
372 Requirement Levels", BCP 14, RFC 2119, March 1997.
374 [RFC-3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
375 RFC 3396, November 2002.
377 10. Informative References
379 [RFC-3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
380 Messages", RFC 3118, June 2001.
382 [RFC-2939] Droms, R., "Procedures and IANA Guidelines for Definition
383 of New DHCP Options and Message Types", BCP 43, RFC 2939,
384 September 2000.
386 [RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
387 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
388 Transfer Protocol -- HTTP/1.1" RFC 2616, June 1999.
390 [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol
391 (FTP)", STD 9, RFC 959, October 1985.
393 [RFC-1436] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
394 D. Torrey and B. Albert, "The Internet Gopher Protocol
395 (a distributed document search and retrieval protocol)",
396 RFC 1436, March 1993.
398 [RFC-977] Kantor, B and P. Lapsley, "Network News Transfer
399 Protocol", RFC 977, February 1986.
401 [RFC-1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
402 L. Jones, "SOCKS Protocol V5", RFC 1928, April 1996.
404 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
405 Corp., Feb 9, 1995.
407 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
408 Protocol", Netscape Communications Corp., Nov 18, 1996.
410 [RFC-1625] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle,
411 J. Kunze, H. Morris, F. Schiettecatte, "WAIS over Z39.50-1988",
412 RFC 1625, June 1994.
414 [RDF-SYN] Becket, D. and B. McBride, Ed., "RDF/XML Syntax Specification",
415 W3C REC-rdf-syntax, February 2004,
416 .
418 Author's Address
420 Senthil K Balasubramanian
421 Intoto Software (I) Pvt Ltd
422 Old No 3, New No 5, First Street,
423 Nandanam Extension,
424 Chennai, India 600 035
426 Phone: +91 44 2827 5191
427 EMail: ksenthil@intoto.com
429 Michael Alexander
430 Wirtschaftsuniversitaet Wien
431 Augasse 2-6
432 A-1090 Vienna, Austria
434 Phone: +43 31336 4467
435 Email: malexand@wu-wien.ac.at
437 Gustaf Neumann
438 Wirtschaftsuniversitaet Wien
439 Augasse 2-6
440 A-1090 Vienna, Austria
442 Phone: +43 31336 4671
443 Email: neumann@wu-wien.ac.at
445 Intellectual Property Statement
447 The IETF takes no position regarding the validity or scope of any
448 Intellectual Property Rights or other rights that might be claimed to
449 pertain to the implementation or use of the technology described in
450 this document or the extent to which any license under such rights
451 might or might not be available; nor does it represent that it has
452 made any independent effort to identify any such rights. Information
453 on the procedures with respect to rights in RFC documents can be
454 found in BCP 78 and BCP 79.
456 Copies of IPR disclosures made to the IETF Secretariat and any
457 assurances of licenses to be made available, or the result of an
458 attempt made to obtain a general license or permission for the use of
459 such proprietary rights by implementers or users of this
460 specification can be obtained from the IETF on-line IPR repository at
461 http://www.ietf.org/ipr.
463 The IETF invites any interested party to bring to its attention any
464 copyrights, patents or patent applications, or other proprietary
465 rights that may cover technology that may be required to implement
466 this standard. Please address the information to the IETF at
467 ietf-ipr@ietf.org.
469 Disclaimer of Validity
471 This document and the information contained herein are provided on an
472 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
473 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
474 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
475 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
476 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
477 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
479 Copyright Statement
481 Copyright (C) The Internet Society (2005). This document is subject
482 to the rights, licenses and restrictions contained in BCP 78, and
483 except as set forth therein, the authors retain all their rights.
485 Acknowledgment
487 Funding for the RFC Editor function is currently provided by the
488 Internet Society.