idnits 2.17.1 draft-pchowdaiah-prefetch-dns-over-http-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2616], [DNS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 205 has weird spacing: '...p-alive that ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 27, 2017) is 2397 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'DNS' is mentioned on line 16, but not defined == Missing Reference: 'RFC 2616' is mentioned on line 218, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC2119' is mentioned on line 93, but not defined == Missing Reference: 'Figure 1' is mentioned on line 128, but not defined == Missing Reference: 'Figure 2' is mentioned on line 180, but not defined == Missing Reference: 'RFC 1034' is mentioned on line 135, but not defined == Unused Reference: 'RFC0793' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC7231' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC7234' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'RFC7235' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC1919' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC1945' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'RFC2068' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC2145' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 342, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 7 errors (**), 0 flaws (~~), 19 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT P.Chowdaiah 3 Intended Status: Experimental (ariksh software) 4 Expires: March 31, 2018 September 27, 2017 6 Method to pre-fetch Domain Names at HTTP Proxy Servers 7 draft-pchowdaiah-prefetch-dns-over-http-01 9 Abstract 11 This specification offers an approach for augmenting domain name 12 resolution times by intercepting HTTP responses at HTTP Proxy servers 13 and triggering DNS queries to the servers in lieu of user requests 14 and returning responses without an explicit requests from clients. 15 This functionality can be achieved by multiple approaches at HTTP and 16 Domain Name System [DNS] Protocols, this document specifies approach 17 that shall be employed at HTTP protocol [RFC 2616]. 18 Methods/approaches pertaining to DNS shall be documented in [draft- 19 pchowdaiah-dns-without-explicit-query.txt]. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Functionality Overview . . . . . . . . . . . . . . . . . . . . 3 62 3. Detailed Specification . . . . . . . . . . . . . . . . . . . . 5 63 3.1. HTTP Header Fields . . . . . . . . . . . . . . . . . . . . 6 64 3.2. HTTP Request Header Fields . . . . . . . . . . . . . . . . 6 65 3.2.1. Dns-prefetch-over-http . . . . . . . . . . . . . . . . 7 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. Dns-prefetch-over-http . . . . . . . . . . . . . . . . . . 7 69 6. Implementation Source Code . . . . . . . . . . . . . . . . . . 8 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 7.3. Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 HTTP proxy servers have information that can be utilized to augment 79 the resolution times of Domain names which could increase the speed 80 of loading web pages on account of domain name resolution being pre 81 resolved by the proxy servers and responses being sent before 82 explicit requests from domain name clients. This document specifies a 83 method to send DNS responses by pre-negotiating a time bound 84 transport layer [TCP and UDP] connection and sending responses on 85 this connection when HTTP Proxy server parses HTTP responses received 86 for an earlier HTTP request. 88 1.1. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2. Functionality Overview 96 [Figure 1] shows high-level generic behavior in HTTP proxies, which 97 is summarized here: A web Browser Client sends HTTP Protocol 98 requests, (transport layer connections are not covered here), the 99 request is received at Proxy, proxy interprets and parses requests 100 into its internal data structures, forwards request to the 101 destination server, on receiving responses from server, proxy updates 102 internal data structures, might cache responses and forwards response 103 back to Browser client. 105 Client HTTPProxy DNSServer HTTPServer 106 ---+--- ----+---- ---+----- ----+----- 107 | ... | | | 108 | | | | 109 |--HTTPReq------>| | | 110 | |[InternalData | | 111 | | creation] | | 112 | | | | 113 | |--Forward Request------------------->| 114 | | | | 115 | |<--------------------------Response--| 116 | |[updateInternal| | 117 | |data] | | 118 | | | | 119 |<------FwdResp--| | | 120 | | | | 121 |--DNSQuery (if any)------------>| | 122 |<------------------DNSResponse--| | 123 | | | | 124 |--HTTPReq------>| | | 125 | ... | | | 126 | | | | 128 [Figure 1] 130 [Figure 2] shows overview of proposed approach: A web browser client 131 sends HTTP Protocol requests, request is received at proxy, proxy 132 parses the requests and does bookkeeping into its internal data 133 structures, forwards request to destination server, on receiving 134 responses from server, proxy parses responses and updates internal 135 data structures and looks for domain name [RFC 1034] queries inside 136 the responses and forwards it to proxy DNS resolver co-located with 137 HTTP proxy implementations, then forwards the received HTTP responses 138 to browsing client. On receiving the DNS query responses, DNS module 139 co-located in the HTTP proxy module constructs agreed implementation 140 specific responses towards the client on the transport layer 141 connection known as 'DNS Pre-fetch Connection' henceforth with pre- 142 negotiated port and protocol specified in the HTTP requests received 143 from the browser client which could be configured or dynamically 144 generated. The browser client then constructs the HTTP requests as 145 per received DNS resolution and proceeds with its activities, thereby 146 avoiding explicit DNS requests. Detailed procedure is documented in 147 section "Detailed Specification" 148 Client HTTPProxy DNSServer HTTPServer 149 ---+--- ----+---- ---+----- ----+----- 150 | ... | | | 151 | | | | 152 | HTTPReq | | | 153 |--WithHeaders-->| | | 154 | | | | 155 | |[InternalData | | 156 | |creation,setup | | 157 | |DNS Pre-fetch | | 158 | |connection etc]| | 159 | | | | 160 | |--Forward Request------------------->| 161 | | | | 162 | |<--------------------------Response--| 163 | | | | 164 | |[updateInternal| | 165 | |data, parse for| | 166 | |DomainName | | 167 | |send DNSQuery] | | 168 | | | | 169 |<------FwdResp--|--DNSQuery---->| | 170 | |<-DNSResponse--| | 171 | | | | 172 | SendDNSResp | | | 173 | onDNSPrefetch | | | 174 |<--Connection-- | | | 175 | | | | 176 |--HTTPReq------>| | | 177 | ... | | | 178 | | | | 180 [Figure 2] 182 3. Detailed Specification 184 Today most of the HTTP proxy designs either transparent or non- 185 transparent probably are proprietary implementations that are based 186 on the knowledge gained through experience and deployments. The 187 approach presented here is also an outcome of this knowledge. Some of 188 the HTTP proxy implementations have full knowledge of the HTTP 189 request and responses as they snoop into the messages that are 190 exchanged between the client and server. This document's approach is 191 to use this information available at the proxies to augment the 192 domain name resolution times by pre-requesting the DNS queries for 193 domain names in the HTTP responses being exchanged, the proxy might 194 cache responses if domain names are found to spill over-to next 195 response packets. If the responses are encrypted then pre-requesting 196 domain names shall be ignored and the responses are just forwarded. 197 Here are the detailed steps that are involved: 199 a. This functionality shall be controlled at the client side with 200 configuration options which needs to be set to have this 201 functionality communicated to the proxies through HTTP message header 202 field. This new HTTP message header field are detailed in section 203 [3.2]. New message headers contain magic security cookie, transport 204 and network layer information on protocol, port, Internet protocol 205 address, timeout for connection keep-alive that client would listen 206 on. The client would setup transport connections ('DNS Pre-fetch 207 Connection') that it shall be listening on with parameters that it 208 shall advertise. Network Address Translation (NAT)-Application Layer 209 gateways (ALG) implementations shall need to be updated for the new 210 functionality. 212 b. Received HTTP request at the proxy is parsed, internal bookkeeping 213 carried out, an optional implementation ACK can be sent back on the 214 connection that client has advertised in item [a]. Received request 215 is forwarded to destination server sans the header specific to this 216 documented functionality. If destination server receives a request 217 having the new HTTP message headers, it needs to do a no-operation on 218 it as per [RFC 2616]. 220 c. On receiving HTTP response from the server, session identified by 221 comparing the book kept data structures. Domain names are retrieved 222 from the parsed responses, limited responses are cached if domain 223 names span across multiple packets, domain names resolution is 224 triggered to co-located DNS server. The HTTP responses is forwarded 225 to the client. 227 d. Domain query responses received from co-located DNS server is 228 forwarded on the connection to the client. Agreement on format of the 229 message that is exchanged would be implementation specific. 230 Implementations shall define formats of message types and information 231 that it needs to be exchanged over DNS-prefetch-connection. 232 Approaches shall include either limited exchanging of specific 233 information from query response or approaches described in [draft- 234 pchowdaiah-dns-without-explicit-query.txt] 236 e. Client with response received on the connection setup for this 237 functionality shall use the domain name resolution information and 238 send out new HTTP requests. 240 3.1. HTTP Header Fields 242 3.2. HTTP Request Header Fields 243 3.2.1. Dns-prefetch-over-http 245 The Dns-prefetch-over-http request header field communicates 246 connection parameters. 248 Dns-prefetch-over-http = "Dns-prefetch-over-http" ":" 249 1#( prefetch-params ) 251 prefetch-params = "magic-cookie" ";" "hostIpAddress" ";" "protocol" 252 ";" "port" ";" "connection timeout" 253 ";" "response timeout" 255 where: 257 magic-cookie : dynamically generated session security 258 authenticator 259 hostIpAddress : Internet protocol address of client 260 protocol : transport layer protocol TCP and UDP 261 port : the port socket listening on 262 connection timeout : keep-alive timeout in seconds 263 response timeout : time client waits for pre-fetch DNS responses 264 before initiating standard DNS query 266 Example of its usage: 268 Dns-prefetch-over-http : MAGICCOOKIE;192.168.1.1;UDP;25001:60;500\r\n 270 4. Security Considerations 272 Any cookie related authentication mechanisms employed shall create 273 security pitfalls. This proposed method shall not have any unknown 274 security issues other than issues similarly identified for the HTTP 275 standard cookie related HTTP header field though both are unrelated. 277 5. IANA Considerations 279 This specification being experimental shall not request any updates 280 to any standard or registry. However upon review if this 281 specification acquires standard status, this specification proposes 282 and requests the following HTTP fields to be included in HTTP message 283 header field registry [see RFC3864]: 285 5.1. Dns-prefetch-over-http 287 Header field name: Dns-prefetch-over-http 289 Applicable protocol: http 290 Status: provisional 292 Author/Change controller: this specification 294 Specification document: this specification (Section 3.2.1) 296 6. Implementation Source Code 298 Proof-of-concept source code shall be available on github at this web 299 link 302 7. References 304 7.1. Normative References 306 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 307 RFC 793, September 1981. 309 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 310 "Uniform Resource Identifier (URI): Generic Syntax", 311 STD 66, RFC 3986, January 2005. 313 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 314 Transfer Protocol (HTTP/1.1): Semantics and Content", 315 RFC 7231, June 2014. 317 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 318 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 319 RFC 7234, June 2014. 321 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 322 Transfer Protocol (HTTP/1.1): Authentication", 323 RFC 7235, June 2014. 325 7.2. Informative References 327 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 328 RFC 1919, March 1996. 330 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 331 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 332 May 1996. 334 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 335 T. Berners-Lee, "Hypertext Transfer Protocol -- 336 HTTP/1.1", RFC 2068, January 1997. 338 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, 339 "Use and Interpretation of HTTP Version Numbers", 340 RFC 2145, May 1997. 342 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 343 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 344 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 346 7.3. Notice 348 Please forward any comments and feedback to parikpub@gmail.com 350 Authors' Addresses 352 Parikshith Chowdaiah 353 ariksh software technologies 354 1578/A, BSK II Stage 355 Bangalore 560070 356 India 358 Email: parikpub@gmail.com