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.