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.