idnits 2.17.1 draft-ietf-dhc-proxyserver-opt-05.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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 175 has weird spacing: '... appear in...' -- 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 (June 2006) is 6525 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-3986' is mentioned on line 76, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 143, but not defined == Missing Reference: 'STD-63' is mentioned on line 193, but not defined == Unused Reference: 'RFC-2119' is defined on line 249, but no explicit reference was found in the text == Unused Reference: 'STD63' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 270, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft Senthil K Balasubramanian 4 Expires: December 2006 Intoto 5 Michael Alexander 6 Gustaf Neumann 7 Wirtschaftsuniversitaet Wien 8 June 2006 10 DHCP Option for Proxy Server Configuration 11 draft-ietf-dhc-proxyserver-opt-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 46 Proxy Server configuration for standard protocols like HTTP,FTP, 47 NNTP,SOCKS, Gopher, SLL and etc. Proxy Server provides controlled 48 and efficient access to the Internet by access control mechanism 49 for 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 55 DHCP Client: A DHCP [RFC-2131] client is an Internet host that 56 uses DHCP to obtain configuration information such as a 57 network address. 59 DHCP Server: A DHCP server [RFC-2131] is an Internet host that 60 returns configuration parameters to DHCP clients. 62 Proxy Server: In an enterprise network that connects to Internet, a 63 proxy server is a server that acts as an intermediary between a 64 workstation user and the Internet so that the enterprise can 65 ensure security and administrative control. A Proxy server MAY 66 provide caching services or be associated with or part of a 67 gateway server that separates the enterprise network from 68 the outside network (usually the Internet) and a firewall 69 that protects the enterprise network from outside intrusion. 71 PAC : PAC stands for Proxy Auto-Configuration. It is a file 72 that contains information about the proxy servers to be used. 73 Most of the browsers support Proxy Auto Configuration File 74 format to specify the proxies to be used. 76 URI : Uniform Resource Identifier [RFC-3986]. A Uniform 77 Resource Identifier is a formatted string that serves as an 78 identifier for a resource, typically on the Internet. The 79 formatted string comprises a name or address that can be used 80 to refer to a internet resource. URIs in common practice include 81 Uniform Resource Locators(URLs). The following are the examples 82 of URI: 84 http://www.ietf.org/rfc/rfc1234.txt 85 ftp://ftp.isi.edu/rfc/rfc124.txt 87 In addition to identifying a resource, the URI also provides a 88 means of acting upon or obtaining a representation of the 89 resource by describing its primary access mechanism. For 90 example, http://www.ietf.org is a URI that identifies a resource 91 and implies that the resource is accessible through HTTP 92 protocol. 94 2. Introduction 96 The Dynamic Host Configuration Protocol [RFC-2131] provides a 97 framework for passing configuration information to hosts on a 98 TCP/IP network. This document describes a DHCP configuration 99 option that can be used to inform a DHCP client of the IP 100 addresses and properties of one or more proxy services that are 101 either available to it or that must be used in order to access 102 internet services, for example through a coporate firewall. 104 The following diagram depicts the typical setup of a proxy server 105 providing proxy services to clients on a network that is protected 106 by a firewall 108 +---------------------------+ +-----------+ 109 | | |Remote HTTP| 110 | | HTTP |Server | 111 | +------------+ +-------------+<--->+-----------+ 112 | | Clients | |Proxy Server | 113 | | Inside the |<------>| + | FTP +-----------+ 114 | | Firewall | |Firewall |<--->|Remote FTP | 115 | +------------+ +-------------+ |Server | 116 | | ^ +-----------+ 117 | | | 118 | | | +-----------+ 119 +---------------------------+ | NNTP |Remote NNTP| 120 +------------>|Server | 121 +-----------+ 123 The primary use of proxies is to allow access to the World Wide Web 124 from within a firewall. A proxy service typically runs on firewall 125 machine. It waits for a request from inside the firewall, forwards 126 the request to the remote server outside the firewall, reads the 127 response and then sends it back to the client. Usually, all the 128 clients use the same proxy within a given network, which helps in 129 efficient caching of documents that are requested by a number of 130 clients. Similarly, proxies can provide document caching functions 131 on the outside Internet. 133 A proxy server can increase network security and user productivity 134 by filtering content and controlling both internal and external 135 access to information. Also, it provides several other 136 functionalities that are not discussed here. 138 3. Requirements terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 142 this document are to be interpreted as described in [RFC 2119]. 144 4. Proxy Server Configuration Option 146 This document defines a new DHCP Option called the Proxy Server 147 Configuration Option. The format of the Proxy Server configuration 148 option is: 150 Code Len Proxy Server Configuration Field 151 +------+------+------+------+------+------+--...-+------+ 152 | TBD | N | i1 | i2 | i3 | i4 | | iN | 153 +------+------+------+------+------+------+--...-+------+ 155 Code is TBD and will be assigned by IANA according to [RFC-2939]. 156 The length N gives the total number of octets in the proxy server 157 configuration field. 159 The Proxy server configuration field consists of SubOpt/Length/Value 160 tuples for each sub-option, encoded in the following manner: 162 SubOpt Len Sub-option Value 163 +------+------+------+------+------+------+--...-+------+ 164 | 1 | N | s1 | s2 | s3 | s4 | | sN | 165 +------+------+------+------+------+------+--...-+------+ 167 SubOpt Len Sub-option Value 168 +------+------+------+------+------+------+--...-+------+ 169 | 2 | N | i1 | i2 | i3 | i4 | | iN | 170 +------+------+------+------+------+------+--...-+------+ 172 The length N of the DHCP Proxy Server Information Option shall 173 include all bytes of the sub-option code/length/value tuples. The 174 length N of the sub-options shall be the number of octets in only 175 that sub-option's value field. The sub-option need not appear in 176 sub-option code order. No pad sub-option is defined, and the proxy 177 server configuration field shall NOT be terminated with a 255 sub- 178 option. The initial assignment of DHCP Proxy Server Sub-options is as 179 follows 181 +------------------+------------------------+ 182 |DHCP Proxy Server | Sub Option Description | 183 |Sub Option Code | | 184 +------------------+------------------------+ 185 | 1 | PAC URI | 186 |------------------+------------------------+ 187 | 2 | MD5 Digest of PAC URI | 188 +------------------+------------------------+ 190 5. Proxy Server Configuration Sub Options 192 5.1 PAC URI Sub Option and MD5 Digest Sub Option of PAC URI 193 The PAC URI Sub Option specifies an URI in the UTF-8[STD-63] format. 194 The length of the sub-option is actually depends on the scheme used 195 to specify an URI. However, it MUST be restricted to a maximum of 255 196 octets. The DHCP Server MAY compute MD5[MD5] digest on the PAC URI 197 configured and send the value in MD5 Digest Sub Option(Sub Option 2). 198 The DHCP Client on receiving this sub-option MUST compute MD5 digest 199 on the URI received in the PAC URI Sub Option and match it with the 200 digest present in MD5 Digest Sub Option. If the calculated MD5 digest 201 doesn't match with the received MD5 digest, then the DHCP client MUST 202 drop this configuration. The PAC URI Sub-Option is as follows: 204 SubOpt Len PAC URI Sub-Option 205 +-----+-----+-----+-----+-----+--...-+------+ 206 | 1 | N | c1 | c2 | c3 | | cN | 207 +-----+-----+-----+-----+-----+--...-+------+ 209 SubOpt Len MD5 Digest Sub Option 210 +-----+-----+-----+-----+-----+--...-+------+ 211 | 2 | N | c1 | c2 | c3 | | cN | 212 +-----+-----+-----+-----+-----+--...-+------+ 214 The MD5 sub option is OPTIONAL and DHCP Server MAY send it if it 215 calculates MD5 digest on the PAC URI. 217 6. Option Usage 219 The DHCP Proxy server configuration option MUST always carry PAC URI 220 Sub Option. However MD5 Digest of PAC URI Sub Option is OPTIONAL. 221 This is provided for additional security. If the length of the Proxy 222 server configuration option exceeds the maximum permissible within a 223 single option (255 octets), then the Configuration Option MUST be 224 represented in the DHCP message as specified in [RFC-3396]. 226 7. Security Considerations 228 The DHCP Options defined here allow an intruder DHCP server to 229 misdirect a client, causing it to access a nonexistent or 230 malicious proxy server. This allows for a denial of service or 231 man-in-the-middle attacks. The latter security consideration is 232 a well known property of the DCHP protocol; this option does not 233 create any additional risk of such attacks. 235 DHCP provides an authentication mechanism, as described in 236 [RFC-3118], which may be used if authentication is required. 238 8. IANA Considerations 240 IANA is requested to assign an option code to the Proxy Server 241 Configuration Option and protocol numbers for the SSL and RDF 242 protocol. 244 9. Normative References 246 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", 247 RFC 2131, March 1997. 249 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC-3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 253 RFC 3396, November 2002. 255 [STD63] Yergeau, F., "UTF-8, a transformation format of 256 ISO 10646", STD 63, RFC 3629, November 2003. 258 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", 259 RFC 1321, April 1992. 261 10. Informative References 263 [RFC-3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 264 Messages", RFC 3118, June 2001. 266 [RFC-2939] Droms, R., "Procedures and IANA Guidelines for 267 Definition of New DHCP Options and Message Types", BCP 43, 268 RFC 2939, September 2000. 270 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 271 Resource Identifiers (URI): Generic Syntax", RFC 3986, 272 January 2005. 274 11. Acknowledgments 276 Thanks to the DHC Working Group for their time and input into the 277 specification. In particular, thanks to (in alphabetical order) 278 Bernie Volz, Ralph Droms, Robert Elz, Stig Venaas and Ted Lemon 279 for their thorough review. 281 Author's Addresses 283 Senthil Kumar Balasubramanian 284 Intoto Software (I) Pvt Ltd., 285 New No 5, Old No 3, First Street, 286 Nandanam Extension, 287 Chennai, India 288 Phone: +91 44 5211 2783/4/5 289 Email: ksenthil@intoto.com 291 Michael Alexander 292 Wirtschaftsuniversitaet Wien 293 Augasse 2-6 294 A-1090 Vienna, Austria 295 Phone: +43 31336 4467 296 Email: malexand@wu-wien.ac.at 298 Gustaf Neumann 299 Wirtschaftsuniversitaet Wien 300 Augasse 2-6 301 A-1090 Vienna, Austria 302 Phone: +43 31336 4671 303 Email: neumann@wu-wien.ac.at 305 Intellectual Property Statement 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at 327 ietf-ipr@ietf.org. 329 Disclaimer of Validity 331 This document and the information contained herein are provided on an 332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 333 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 334 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 335 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 336 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 339 Copyright Statement 341 Copyright (C) The Internet Society (2006). This document is subject 342 to the rights, licenses and restrictions contained in BCP 78, and 343 except as set forth therein, the authors retain all their rights. 345 Acknowledgment 347 Funding for the RFC Editor function is currently provided by the 348 Internet Society.