idnits 2.17.1
draft-ietf-dhc-proxyserver-opt-04.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.1 on line 47.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 483.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 460.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 467.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 473.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
489), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 40.
** 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.
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 10
longer pages, the longest (page 1) being 65 lines
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 10 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 19 instances of too long lines in the document, the longest
one being 11 characters in excess of 72.
** There are 58 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:
A Proxy Server Configuration Entry with more than one RDF type of
MUST not be sent in this option. This is because the RDF Meta Data is
generally more than 255 octets and always requires 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 (July 2005) is 6853 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 130, but not defined
== Unused Reference: 'RFC-2119' is defined on line 377, but no explicit
reference was found in the text
== Unused Reference: 'RFC-2616' is defined on line 392, but no explicit
reference was found in the text
== Unused Reference: 'RFC-959' is defined on line 396, but no explicit
reference was found in the text
== Unused Reference: 'RFC-1436' is defined on line 399, but no explicit
reference was found in the text
== Unused Reference: 'RFC-977' is defined on line 404, but no explicit
reference was found in the text
== Unused Reference: 'RFC-1928' is defined on line 407, but no explicit
reference was found in the text
== Unused Reference: 'SSL2' is defined on line 410, but no explicit
reference was found in the text
== Unused Reference: 'SSL3' is defined on line 413, but no explicit
reference was found in the text
== Unused Reference: 'RFC-1625' is defined on line 416, 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: 7 errors (**), 0 flaws (~~), 16 warnings (==), 10 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: December 2005 Michael Alexander
4 Gustaf Neumann
5 Wirtschaftsuniversitaet Wien
6 July 2005
8 DHCP Option for Proxy Server Configuration
9 draft-ietf-dhc-proxyserver-opt-04.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 IPR Statement
43 By submitting this Internet-Draft, each author represents
44 that any applicable patent or other IPR claims of which he
45 or she is aware have been or will be disclosed, and any of
46 which he or she becomes aware will be disclosed, in
47 accordance with Section 6 of BCP 79.
49 Abstract
51 This document defines a new Dynamic Host Configuration Protocol
52 (DHCP) option, which can be used to configure Proxy Servers in
53 TCP/IP for standard protocols like HTTP, FTP, NNTP, SOCKS, SNMP,
54 SLL and etc. Proxy Servers provide controlled and efficient access
55 to the Internet, include access control mechanisms for different
56 types of user requests and cache frequently accessed information
57 (Web pages and possibly files that might have been downloaded
58 using FTP and other protocols).
60 1. Terminologies Used
61 DHCP Client: A DHCP [RFC-2131] client is an Internet host that
62 uses DHCP to obtain configuration information such as a
63 network address.
65 DHCP Server: A DHCP server [RFC-2131] is an Internet host that
66 returns configuration parameters to DHCP clients.
68 Proxy Server: In an enterprise network that connects to Internet,
69 a proxy server is a server that acts as an intermediary
70 between a workstation user and the Internet so that the
71 enterprise can ensure security and administrative control.
72 A Proxy server MAY provide caching services or be
73 associated with or part of a gateway server that separates
74 the enterprise network from the outside network (usually
75 the Internet) and a firewall that protects the enterprise
76 network from outside intrusion.
78 RDF:A language (Resource Description Framework [RDF-SYN]) for
79 describing properties of web resources.
81 2. Introduction
83 The Dynamic Host Configuration Protocol [RFC-2131] provides a
84 framework for passing configuration information to hosts on a TCP/IP
85 network. This document describes a DHCP configuration option that
86 can be used to inform a DHCP client of the IP addresses and properties
87 of one or more proxy services that are either available to it or that
88 must be used in order to access internet services, for example through
89 a coporate firewall.
91 The following diagram depicts the typical setup of a proxy server
92 providing proxy services to clients on a network that is protected
93 by a firewall.
95 +---------------------------+ +-----------+
96 | | |Remote HTTP|
97 | | HTTP |Server |
98 | +------------+ +-------------+<--->+-----------+
99 | | Clients | |Proxy Server |
100 | | Inside the |<------>| + | FTP +-----------+
101 | | Firewall | |Firewall |<--->|Remote FTP |
102 | +------------+ +-------------+ |Server |
103 | | ^ +-----------+
104 | | |
105 | | | +-----------+
106 +---------------------------+ | NNTP |Remote NNTP|
107 +------------>|Server |
108 +-----------+
110 The primary use of proxies is to allow access to the World Wide Web
111 from within a firewall. A proxy service typically runs on firewall
112 machine. It waits for a request from inside the firewall, forwards
113 the request to the remote server outside the firewall, reads the
114 response and then sends it back to the client. Usually, all the
115 clients use the same proxy within a given network, which helps in
116 efficient caching of documents that are requested by a number of
117 clients. Similarly, proxies can provide document caching functions
118 on the outside Internet.
120 A proxy server can increase network security and user productivity
121 by filtering content and controlling both internal and external
122 access to information. Also, it provides several other
123 functionalities that are not discussed here.
125 3. Requirements terminology
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
129 document are to be interpreted as described in [RFC 2119].
131 4. Proxy Server Configuration Option
133 This document defines a new DHCP Option called the Proxy Server
134 Configuration Option. The format of the Proxy Server configuration
135 option is:
137 Code Len Proxy Server Configuration Entry
138 +-------+------+------+------+------+------+-....-+------+
139 | TBD | N | e1 | e2 | e3 | e4 | | en |
140 +-------+------+------+------+------+------+-....-+------+
142 Code is TBD and will be assigned by IANA according to [RFC-2939].
143 The length N gives the total number of octets in the Proxy Server
144 Configuration entries.
146 The Proxy Server Configuration entry normally consists of a
147 sequence of Protocol Type (p), len (l), flag (f), IP
148 address and port. But it can also be a sequence of Protocol
149 Type (p), Len and RDF[RDF-SYN] metadata.
151 +--+--+--+--+--+--+--+--+--+
152 |p |l | f |IP address|port |
153 +--+--+--+--+--+--+--+--+--+
155 The Protocol(p) is a two octet integer in network byte order,
156 length (l) and flag (f) are one octet each; each IP
157 address is four octets, and each port number is a two-octet
158 integer encoded in network byte order.
160 The protocol type(p) specifies the type of protocol and MUST be
161 one of the following assigned numbers.
163 +-------------------------------+
164 | protocol | Number |
165 +-------------------------------+
166 | HTTP | 80 |
167 +-------------------------------+
168 | FTP | 21 |
169 +-------------------------------+
170 | NNTP | 119 |
171 +-------------------------------+
172 | Gopher | 70 |
173 +-------------------------------+
174 | SSL | TBD |
175 +-------------------------------+
176 | SOCKS | 1080 |
177 +-------------------------------+
178 | WAIS | 210 |
179 +-------------------------------+
180 | IMAP | 220 |
181 +-------------------------------+
182 | RDF | TBD |
183 +-------------------------------+
185 If the protocol type field is RDF[RDF-SYN], then it MUST be
186 followed by len (length of RDF metadata) and the actual RDF
187 metadata.
189 The length field (l) specifies the length of the Proxy Server
190 Configuration entry. If some new protocol is introduced in the
191 future, and if some version of a given dhcpclient doesn't support
192 it, then that particular entry can be ignored. If it exists, the
193 next following Proxy Server Configuration Entry can be processed.
195 The flag field (f) is by default 0. Otherwise, it can either
196 have "-" or "#".
198 If it is "-", then the entry becomes a destination address for
199 exclusion from forwarding to the proxy. If it is "#", then the proxy
200 requires authentication.
202 In cases where it makes sense to specify more than one proxy server
203 for a given protocol, these proxy servers MUST be specified as
204 additional IP addresses and ports within the same entry. The list is
205 ordered by precedence, with the most preferred proxy server appearing
206 first in the list, and the least preferred proxy server appearing last
207 in the list. The DHCP client SHOULD honor this ordering.
209 More than one Proxy Server Configuration Entries MAY be specified in
210 the option. In that case, the list is ordered by precedence, with
211 the most preferred proxy server appearing first in the list, and the
212 least preferred proxy server appearing last in the list. The DHCP
213 client SHOULD honor this ordering.
215 The format of the Proxy Server Configuration using Metadata type is:
217 p Len RDF Metadata for the Proxy
218 +-------+------+----------------------------------+
219 | RDF | N | RDF |
220 +-------+------+----------------------------------+
222 The RDF payload is freeform RDF metadata for describing proxy
223 properties. The length N gives the number of octets in the RDF
224 metadata field.
226 The following entry specifies the sample format of the RDF Meta
227 data field
229 HTTP proxy:
231
232 ]>
233
235
236 License Gate Proxy
237 John Doe
238 example.com IS
239 Offsite Resource Access Proxy
240 Service
241 example.com employees
242 2005-07-11
243
244
246 FTP proxy:
248
249 ]>
250
252
253 License Gate FTP Proxy
254 John Doe
255 example.com IS
256 Offsite Resource Access Proxy
257 Service
258 example.com employees
259 2005-07-11
260
261
263 As such there is no minimum length to specify a proxy using RDF
264 metadata. But the minimum sensible statement would be a literal
265 description of the proxy (License Gate Proxy)
266 giving a total of 418 characters including the overhead.
268 For example, with a description element of 60 characters, an URI of
269 80 characters plus a minimum XML/RDF syntax conformation/namespace
270 declaration from below the minimum length would be 418 octes.
272 21 Octets
273 70 Octets ]>
274 64 Octets
276 109 Octets
277 81 Octets ..60 characters..
278 18 Octets
279 10 Octets
281 5. Option Usage
283 The Proxy Server Configuration entries SHOULD not repeat the same
284 type of proxy entries. The port MUST be a valid TCP/UDP port.
285 If the length of the Proxy Server Configuration Option exceeds the
286 maximum permissible within a single option (255 octets), then the
287 option MUST be represented in the DHCP message as specified
288 in [RFC-3396].
290 The following example shows how an RDF version of proxy server
291 configuration entry of 400 octets is represented in the option.
293 Code Len Proto Len
294 +-------+------+------+------+------+------+-....-+------+
295 | TBD | 255 | RDF | 253 | RDF Meta Data.............|
296 +-------+------+------+------+------+------+-....-+------+
297 Code Len Proto Len
298 +-------+------+------+------+------+------+-....-+------+
299 | TBD | 149 | RDF | 147 | RDF Meta Data.............|
300 +-------+------+------+------+------+------+-....-+------+
302 The following example shows how a proxy server configuration entry
303 of 400 octets is represented in RDF along with the normal
304 (p|l|f|IP|port) format.
306 +---+---+----+-+-+-------------+----+---+---+...-+---+-----+
307 |TBD|255|HTTP|7|0|192.168.5.10 |8080|RDF|243| RDF Meta Data|
308 +---+---+----+-+-+-------------+----+---+---+...-+---+-----+
310 +-------+------+------+------+------+------+-....-+------+
311 | TBD | 159 | RDF | 157 | RDF Meta Data.............|
312 +-------+------+------+------+------+------+-....-+------+
314 A Proxy Server Configuration Entry with more than one RDF type
315 of MUST not be sent in this option. This is because the RDF Meta
316 Data is generally more than 255 octets and always requires more
317 than one option of this type as per [RFC-3396]. However, more than one
318 proxy server configuration (FTP, HTTP, SOCKS) can be specified with
319 the same RDF Meta Data as follows:
321 HTTP and FTP Proxy
323
324 ]>
325
327
328 License Gate Proxy
329 John Doe
330 example.com IS
331 Offsite Resource Access Proxy
332 Service
333 example.com employees
334 2005-07-11
335
336
337 License Gate FTP Proxy
338 John Doe
339 example.com IS
340 Offsite Resource Access Proxy
341 Service
342 example.com employees
343 2005-07-11
344
345
347 6. Security Considerations
349 The DHCP Options defined here allow an intruder DHCP server to
350 misdirect a client, causing it to access a nonexistent or malicious
351 proxy server. This allows for a denial of service or man-in-the-middle
352 attacks. The latter security consideration is a well known property of
353 the DCHP protocol; this option does not create any additional risk
354 of such attacks.
356 DHCP provides an authentication mechanism, as described in [RFC-3118],
357 which may be used if authentication is required.
359 7. IANA Considerations
361 IANA is requested to assign an option code to the Proxy Server
362 Configuration Option and protocol numbers for the SSL and RDF
363 protocol.
365 8. Acknowledgements
367 Thanks to the DHC Working Group for their time and input into the
368 specification. In particular, thanks to (in alphabetical order)
369 Bernie Volz, Ralph Droms, Robert Elz, and Ted Lemon for their
370 thorough review.
372 9. Normative References
374 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
375 March 1997.
377 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
378 Requirement Levels", BCP 14, RFC 2119, March 1997.
380 [RFC-3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
381 RFC 3396, November 2002.
383 10. Informative References
385 [RFC-3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
386 Messages", RFC 3118, June 2001.
388 [RFC-2939] Droms, R., "Procedures and IANA Guidelines for Definition
389 of New DHCP Options and Message Types", BCP 43, RFC 2939,
390 September 2000.
392 [RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
393 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
394 Transfer Protocol -- HTTP/1.1" RFC 2616, June 1999.
396 [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol
397 (FTP)", STD 9, RFC 959, October 1985.
399 [RFC-1436] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
400 D. Torrey and B. Albert, "The Internet Gopher Protocol
401 (a distributed document search and retrieval protocol)",
402 RFC 1436, March 1993.
404 [RFC-977] Kantor, B and P. Lapsley, "Network News Transfer
405 Protocol", RFC 977, February 1986.
407 [RFC-1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
408 L. Jones, "SOCKS Protocol V5", RFC 1928, April 1996.
410 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
411 Corp., Feb 9, 1995.
413 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
414 Protocol", Netscape Communications Corp., Nov 18, 1996.
416 [RFC-1625] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle,
417 J. Kunze, H. Morris, F. Schiettecatte, "WAIS over Z39.50-1988",
418 RFC 1625, June 1994.
420 [RDF-SYN] Becket, D. and B. McBride, Ed., "RDF/XML Syntax Specification",
421 W3C REC-rdf-syntax, February 2004,
422 .
424 Authors' Addresses
426 Senthil K Balasubramanian
427 Intoto Software (I) Pvt Ltd
428 Old No 3, New No 5, First Street,
429 Nandanam Extension,
430 Chennai, India 600 035
432 Phone: +91 44 5211 2783/4/5
433 EMail: ksenthil@intoto.com
435 Michael Alexander
436 Wirtschaftsuniversitaet Wien
437 Augasse 2-6
438 A-1090 Vienna, Austria
440 Phone: +43 31336 4467
441 Email: malexand@wu-wien.ac.at
443 Gustaf Neumann
444 Wirtschaftsuniversitaet Wien
445 Augasse 2-6
446 A-1090 Vienna, Austria
448 Phone: +43 31336 4671
449 Email: neumann@wu-wien.ac.at
451 Intellectual Property Statement
453 The IETF takes no position regarding the validity or scope of any
454 Intellectual Property Rights or other rights that might be claimed to
455 pertain to the implementation or use of the technology described in
456 this document or the extent to which any license under such rights
457 might or might not be available; nor does it represent that it has
458 made any independent effort to identify any such rights. Information
459 on the procedures with respect to rights in RFC documents can be
460 found in BCP 78 and BCP 79.
462 Copies of IPR disclosures made to the IETF Secretariat and any
463 assurances of licenses to be made available, or the result of an
464 attempt made to obtain a general license or permission for the use of
465 such proprietary rights by implementers or users of this
466 specification can be obtained from the IETF on-line IPR repository at
467 http://www.ietf.org/ipr.
469 The IETF invites any interested party to bring to its attention any
470 copyrights, patents or patent applications, or other proprietary
471 rights that may cover technology that may be required to implement
472 this standard. Please address the information to the IETF at
473 ietf-ipr@ietf.org.
475 Disclaimer of Validity
477 This document and the information contained herein are provided on an
478 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
479 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
480 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
481 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
482 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
483 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
485 Copyright Statement
487 Copyright (C) The Internet Society (2005). This document is subject
488 to the rights, licenses and restrictions contained in BCP 78, and
489 except as set forth therein, the authors retain all their rights.
491 Acknowledgment
493 Funding for the RFC Editor function is currently provided by the
494 Internet Society.