idnits 2.17.1 draft-ietf-dnsop-edns-tcp-keepalive-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3470 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: 'TBD' is mentioned on line 202, but not defined == Missing Reference: 'TBA' is mentioned on line 353, but not defined == Unused Reference: 'RFC5966' is defined on line 382, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-ietf-dnsop-edns-chain-query (ref. 'CHAIN-QUERY') ** Obsolete normative reference: RFC 5966 (Obsoleted by RFC 7766) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track J. Abley 5 Expires: April 30, 2015 Dyn, Inc. 6 October 27, 2014 8 The edns-tcp-keepalive EDNS0 Option 9 draft-ietf-dnsop-edns-tcp-keepalive-01 11 Abstract 13 DNS messages between clients and servers may be received over either 14 UDP or TCP. UDP transport involves keeping less state on a busy 15 server, but can cause truncation and retries over TCP. Additionally, 16 UDP can be exploited for reflection attacks. Using TCP would reduce 17 retransmits and amplification. However, clients are currently 18 limited in their use of the TCP transport as RFC 5966 suggests 19 closing idle TCP sessions "in the order of seconds", making use of 20 TCP only suitable for individual queries generated as a fallback 21 protocol for truncated UDP answers. 23 This document defines an EDNS0 option ("edns-tcp-keepalive") that 24 allows DNS clients and servers to signal their respective readiness 25 to conduct multiple DNS transactions over individual TCP sessions. 26 This signalling facilitates a better balance of UDP and TCP transport 27 between individual clients and servers, reducing the impact of 28 problems associated with UDP transport and allowing the state 29 associated with TCP transport to be managed effectively with minimal 30 impact on the DNS transaction time. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 30, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 68 3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 4 69 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5 71 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5 72 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6 73 3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6 74 3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6 75 3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6 76 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7 77 3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 7 78 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 7 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 84 7.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 9 86 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 A.2. Abridged Change History . . . . . . . . . . . . . . . . . 9 88 A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 9 89 A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 9 90 A.2.3. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 9 91 A.2.4. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 9 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 94 1. Introduction 95 DNS messages between clients and servers may be received over either 96 UDP or TCP [RFC1035]. Historically, DNS clients used API's that only 97 facilitated sending and receiving a single query over either UDP or 98 TCP. New APIs and deployment of DNSSEC validating resolvers on hosts 99 that in the past were using stub resolving only is increasing the DNS 100 client base that prefer using long lived TCP connections. Long-lived 101 TCP connections can result in lower request latency than the case 102 where UDP transport is used and truncated responses are received, 103 since clients that have fallen back to TCP transport in response to a 104 truncated response typically only uses the TCP session for a single 105 (request, response) pair, continuing with UDP transport for 106 subsequent queries. 108 UDP transport is stateless, and hence presents a much lower resource 109 burden on a busy DNS server than TCP. An exchange of DNS messages 110 over UDP can also be completed in a single round trip between 111 communicating hosts, resulting in optimally-short transaction times. 112 UDP transport is not without its risks, however. 114 A single-datagram exchange over UDP between two hosts can be 115 exploited to enable a reflection attack on a third party. Mitigation 116 of such attacks on authoritative-only servers is possible using an 117 approach known as Response Rate-Limiting [RRL], an approach designed 118 to minimise the frequency at which legitimate responses are discarded 119 by truncating responses that appear to be motivated by an attacker, 120 forcing legitimate clients to re-query using TCP transport. 122 [RFC1035] specified a maximum DNS message size over UDP transport of 123 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols 124 subsequently increased the observed frequency at which responses 125 exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than 126 512 bytes to be exchanged over UDP, with a corresponding increased 127 incidence of fragmentation. Fragmentation is known to be problematic 128 in general, and has also been implicated in increasing the risk of 129 cache poisoning attacks. 131 The use of TCP transport does not suffer from the risks of 132 fragmentation nor reflection attacks. However, TCP transport as 133 currently deployed has expensive overhead. 135 The overhead of the three-way TCP handshake for a single DNS 136 transaction is substantial, increasing the transaction time for a 137 single (request, response) pair of DNS messages from 1 x RTT to 2 x 138 RTT. There is no such overhead for a session that is already 139 established, however, and the overall impact of the TCP setup 140 handshake when the resulting session is used to exchange N DNS 141 message pairs over a single session, (1 + N)/N, approaches unity as N 142 increases. 144 (It should perhaps be noted that the overhead for a DNS transaction 145 over UDP truncacated due to RRL is 3x RTT, higher than the overhead 146 imposed on the same transaction initiated over TCP.) 148 With increased deployment of DNSSEC and new RRtypes containing 149 application specific cryptographic material, there is an increase in 150 the prevalence of truncated responses received over UDP with fallback 151 to TCP. 153 The use of TCP transport requires considerably more state to be 154 retained on DNS servers. If a server is to perform adequately with a 155 significant query load received over TCP, it must manage its 156 available resources to ensure that all established TCP sessions are 157 well-used, and that those which are unlikely to be used for the 158 exchange of multiple DNS messages are closed promptly. 160 This document proposes a signalling mechanism between DNS clients and 161 servers that provides a means to better balance the use of UDP and 162 TCP transport, reducing the impact of problems associated with UDP 163 whilst constraining the impact of TCP on response times and server 164 resources to a manageable level. 166 The reduced overhead of this extension adds up significantly when 167 combined with other edns extensions, such as [CHAIN-QUERY]. The 168 combination of these two EDNS extensions make it possible for hosts 169 on high-latency mobile networks to natively perform DNSSEC 170 validation. 172 2. Requirements Notation 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 3. The edns-tcp-keepalive Option 180 This document specifies a new EDNS0 [RFC6891] option, edns-tcp- 181 keepalive, which can be used by DNS clients and servers to signal a 182 willingness to keep an (idle) TCP session open for a certain amount 183 of time to conduct future DNS transactions. This specification does 184 not distinguish between different types of DNS client and server in 185 the use of this option. 187 3.1. Option Format 189 The edns-tcp-keepalive option is encoded as follows: 191 1 2 3 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 193 +-------------------------------+-------------------------------+ 194 ! OPTION-CODE ! OPTION-LENGTH ! 195 +-------------------------------+-------------------------------+ 196 | TIMEOUT | 197 +---------------------------------------------------------------+ 199 where: 201 OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, 202 [TBD] 204 OPTION-LENGTH: the value 2; 206 TIMEOUT: a timeout value for the TCP connection, specified in 207 seconds, encoded in network byte order. 209 3.2. Use by DNS Clients 211 3.2.1. Sending Queries 213 DNS clients MAY include the edns-tcp-keepalive option in queries sent 214 using UDP transport to signal their general ability to use individual 215 TCP sessions for multiple DNS transactions with a particular server. 217 DNS clients MAY include the edns-tcp-keepalive option in the first 218 query sent to a server using TCP transport to signal their desire 219 that that specific TCP session be used for multiple DNS transactions. 221 Clients MAY specify a TIMEOUT value that is representative of the 222 minimum expected time an individual TCP session should remain 223 established for it to be used by multiple DNS transactions. 225 In the case where there are multiple candidate servers available to 226 service a particular transaction, clients MAY include data associated 227 with all servers when computing a TIMEOUT value to be signalled to 228 any one of those servers. 230 If the client has insufficient data to be able to provide a 231 meaningful estimate, the TIMEOUT value MUST be set to zero. 233 3.2.2. Receiving Responses 235 A DNS client that receives a response using UDP transport that 236 includes the edns-tcp-keepalive option MAY record the presence of the 237 option and the associated TIMEOUT value, and use that information as 238 part of its server selection algorithm in the case where multiple 239 candidate servers are available to service a particular query. 241 A DNS client that receives a response using TCP transport that 242 includes the edns-tcp-keepalive option MAY keep the existing TCP 243 session open. 245 A DNS client that receives a response that includes the edns-tcp- 246 keepalive option with a TIMEOUT value of 0 is allowed to keep the TCP 247 connection open indefinately. 249 3.3. Use by DNS Servers 251 3.3.1. Receiving Queries 253 A DNS server that receives a query using UDP transport that includes 254 the edns-tcp-keepalive option MAY record the presence of the option 255 for statistical purposes, but should not otherwise modify its usual 256 behaviour in sending a response. 258 A DNS server that receives a query using TCP transport that includes 259 the edns-tcp-keepalive option SHOULD extend the timeout normally 260 associated with TCP sessions if resources permit, using the TIMEOUT 261 value supplied by the client as a guide. 263 3.3.2. Sending Responses 265 DNS servers MAY include the edns-tcp-keepalive option in responses 266 sent using UDP transport to signal their general ability to use 267 individual TCP sessions for multiple DNS transactions with a 268 particular server. The TIMEOUT value should be indicative of what a 269 client might expect if it was to open a TCP session with the server 270 and receive a response with the edns-tcp-keepalive option present. 271 The DNS server MAY omit including the edns-tcp-keepalive option if it 272 is running too low on resources to service more TCP keepalive 273 sessions. 275 DNS servers MAY include the edns-tcp-keepalive option in responses 276 sent using TCP transport to signal their ability to use that specific 277 session to exchange multiple DNS transactions. Servers MUST specify 278 the TIMEOUT value that is currently associated with the TCP session. 279 It is reasonable for this value to change according to local resource 280 constraints. The DNS server MAY omit including the edns-tcp- 281 keepalive option if it deems its local resources are too low to 282 service more TCP keepalive sessions. 284 3.4. TCP Session Management 286 Both DNS clients and servers are subject to resource constraints 287 which will limit the extent to which TCP sessions can persist. 288 Effective limits for the number of active sessions that can be 289 maintained on individual clients and servers should be established, 290 either as configuration options or by interrogation of process limits 291 imposed by the operating system. 293 In the event that there is greater demand for TCP sessions than can 294 be accommodated, servers may reduce the TIMEOUT value signalled in 295 successive DNS messages to avoid abrupt termination of a session. 296 This allows, for example, clients with other candidate servers to 297 query to establish new TCP sessions with different servers in 298 expectation that an existing session is likely to be closed, or to 299 fall back to UDP. 301 DNS clients and servers MAY close a TCP session at any time in order 302 to manage local resource constraints. The algorithm by which clients 303 and servers rank active TCP sessions in order to determine which to 304 close is not specified in this document. 306 3.5. Non-Clean Paths 308 Many paths between DNS clients and servers suffer from poor hygiene, 309 limiting the free flow of DNS messages that include particular EDNS0 310 options, or messages that exceed a particular size. A fallback 311 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 312 be employed to avoid persistent interference due to non-clean paths. 314 3.6. Anycast Considerations 316 DNS servers of various types are commonly deployed using anycast 317 [RFC4786]. 319 Successive DNS transactions between a client and server using UDP 320 transport may involve responses generated by different anycast nodes, 321 and the use of anycast in the implementation of a DNS server is 322 effectively undetectable by the client. The edns-tcp-keepalive 323 option SHOULD NOT be included in responses using UDP transport from 324 servers provisioned using anycast unless all anycast server nodes are 325 capable of processing the edns-tcp-keepalive option. 327 Changes in network topology between clients and anycast servers may 328 cause disruption to TCP sessions making use of edns-tcp-keepalive 329 more often than with TCP sessions that omit it, since the TCP 330 sessions are expected to be longer-lived. Anycast servers MAY make 331 use of TCP multipath [RFC6824] to anchor the server side of the TCP 332 connection to an unambiguously-unicast address in order to avoid 333 disruption due to topology changes. 335 4. Security Considerations 337 The edns-tcp-keep-alive option can potentially be abused to request 338 large numbers of sessions in a quick burst. When a Nameserver 339 detects abusive behaviour, it SHOULD immediately close the TCP 340 connection and free all buffers used. 342 This section needs more work. As usual. 344 5. IANA Considerations 346 The IANA is directed to assign an EDNS0 option code for the edns-tcp- 347 keepalive option from the DNS EDNS0 Option Codes (OPT) registry as 348 follows: 350 +-------+--------------------+----------+-----------------+ 351 | Value | Name | Status | Reference | 352 +-------+--------------------+----------+-----------------+ 353 | [TBA] | edns-tcp-keepalive | Optional | [This document] | 354 +-------+--------------------+----------+-----------------+ 356 6. Acknowledgements 358 The authors acknowledge the contributions of Ray Bellis, Jinmei 359 TATUYA and Mark Andrews. 361 7. References 363 7.1. Normative References 365 [CHAIN-QUERY] 366 Wouters, P., "chain Query requests in DNS", draft-ietf- 367 dnsop-edns-chain-query (work in progress), October 2014. 369 [RFC1035] Mockapetris, P., "Domain names - implementation and 370 specification", STD 13, RFC 1035, November 1987. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 376 Rose, "DNS Security Introduction and Requirements", RFC 377 4033, March 2005. 379 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 380 Services", BCP 126, RFC 4786, December 2006. 382 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 383 Requirements", RFC 5966, August 2010. 385 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 386 "TCP Extensions for Multipath Operation with Multiple 387 Addresses", RFC 6824, January 2013. 389 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 390 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 392 7.2. Informative References 394 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 395 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012. 397 Appendix A. Editors' Notes 399 A.1. Venue 401 An appropriate venue for discussion of this document is 402 dnsop@ietf.org. 404 A.2. Abridged Change History 406 A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-01 408 Version bump with no changes 410 A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-00 412 Clarifications, working group adoption. 414 A.2.3. draft-wouters-edns-tcp-keepalive-01 416 Also allow clients to specify KEEPALIVE timeout values, clarify 417 motivation of document. 419 A.2.4. draft-wouters-edns-tcp-keepalive-00 421 Initial draft. 423 Authors' Addresses 425 Paul Wouters 426 Red Hat 428 Email: pwouters@redhat.com 430 Joe Abley 431 Dyn, Inc. 432 470 Moore Street 433 London, ON N6C 2C2 434 Canada 436 Phone: +1 519 670 9327 437 Email: jabley@dyn.com