idnits 2.17.00 (12 Aug 2021) /tmp/idnits43157/draft-ietf-dnsop-edns-tcp-keepalive-02.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 (July 3, 2015) is 2513 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 208, but not defined == Missing Reference: 'TBA' is mentioned on line 374, but not defined == Unused Reference: 'RFC5966' is defined on line 399, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5966 (Obsoleted by RFC 7766) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) == Outdated reference: draft-ietf-dnsop-edns-chain-query has been published as RFC 7901 == Outdated reference: draft-ietf-dnsop-5966bis has been published as RFC 7766 -- Unexpected draft version: The latest known version of draft-ietf-dprive-start-tls-for-dns is -01, but you're referring to -02. Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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: January 4, 2016 Dyn, Inc. 6 S. Dickinson 7 Sinodun 8 R. Bellis 9 ISC 10 July 3, 2015 12 The edns-tcp-keepalive EDNS0 Option 13 draft-ietf-dnsop-edns-tcp-keepalive-02 15 Abstract 17 DNS messages between clients and servers may be received over either 18 UDP or TCP. UDP transport involves keeping less state on a busy 19 server, but can cause truncation and retries over TCP. Additionally, 20 UDP can be exploited for reflection attacks. Using TCP would reduce 21 retransmits and amplification. However, clients commonly use TCP 22 only for fallback and servers typically use idle timeouts on the 23 order of seconds. 25 This document defines an EDNS0 option ("edns-tcp-keepalive") that 26 allows DNS servers to signal a variable idle timeout. This 27 signalling facilitates a better balance of UDP and TCP transport 28 between individual clients and servers, reducing the impact of 29 problems associated with UDP transport and allowing the state 30 associated with TCP transport to be managed effectively with minimal 31 impact on the DNS transaction time. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 4, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 69 3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 4 70 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5 72 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5 73 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 5 74 3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6 75 3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6 76 3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6 77 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 6 78 3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 7 79 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 7 80 4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 8.2. Informative References . . . . . . . . . . . . . . . . . 9 87 Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 10 88 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 A.2. Abridged Change History . . . . . . . . . . . . . . . . . 10 90 A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 10 91 A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 11 92 A.2.3. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 11 93 A.2.4. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 11 94 A.2.5. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 11 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 97 1. Introduction 99 DNS messages between clients and servers may be received over either 100 UDP or TCP [RFC1035]. Historically, DNS clients used API's that only 101 facilitated sending and receiving a single query over either UDP or 102 TCP. New APIs and deployment of DNSSEC validating resolvers on hosts 103 that in the past were using stub resolving only is increasing the DNS 104 client base that prefer using long lived TCP connections. Long-lived 105 TCP connections can result in lower request latency than the case 106 where UDP transport is used and truncated responses are received, 107 since clients that have fallen back to TCP transport in response to a 108 truncated response typically only uses the TCP session for a single 109 (request, response) pair, continuing with UDP transport for 110 subsequent queries. Clients wishing to use other stream-based 111 transport protocols for DNS would also benefit from the set-up 112 amortisation afforded by long lived connections. 114 UDP transport is stateless, and hence presents a much lower resource 115 burden on a busy DNS server than TCP. An exchange of DNS messages 116 over UDP can also be completed in a single round trip between 117 communicating hosts, resulting in optimally-short transaction times. 118 UDP transport is not without its risks, however. 120 A single-datagram exchange over UDP between two hosts can be 121 exploited to enable a reflection attack on a third party. Mitigation 122 of such attacks on authoritative-only servers is possible using an 123 approach known as Response Rate-Limiting [RRL], an approach designed 124 to minimise the frequency at which legitimate responses are discarded 125 by truncating responses that appear to be motivated by an attacker, 126 forcing legitimate clients to re-query using TCP transport. 128 [RFC1035] specified a maximum DNS message size over UDP transport of 129 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols 130 subsequently increased the observed frequency at which responses 131 exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than 132 512 bytes to be exchanged over UDP, with a corresponding increased 133 incidence of fragmentation. Fragmentation is known to be problematic 134 in general, and has also been implicated in increasing the risk of 135 cache poisoning attacks. 137 The use of TCP transport does not suffer from the risks of 138 fragmentation nor reflection attacks. However, TCP transport as 139 currently deployed has expensive overhead. 141 The overhead of the three-way TCP handshake for a single DNS 142 transaction is substantial, increasing the transaction time for a 143 single (request, response) pair of DNS messages from 1 x RTT to 2 x 144 RTT. There is no such overhead for a session that is already 145 established, however, and the overall impact of the TCP setup 146 handshake when the resulting session is used to exchange N DNS 147 message pairs over a single session, (1 + N)/N, approaches unity as N 148 increases. 150 (It should perhaps be noted that the overhead for a DNS transaction 151 over UDP truncated due to RRL is 3x RTT, higher than the overhead 152 imposed on the same transaction initiated over TCP.) 154 With increased deployment of DNSSEC and new RRtypes containing 155 application specific cryptographic material, there is an increase in 156 the prevalence of truncated responses received over UDP with fallback 157 to TCP. 159 The use of TCP transport requires considerably more state to be 160 retained on DNS servers. If a server is to perform adequately with a 161 significant query load received over TCP, it must manage its 162 available resources to ensure that all established TCP sessions are 163 well-used, and those that remain idle for long periods are closed 164 promptly. 166 This document proposes a signalling mechanism between DNS clients and 167 servers that provides a means to better balance the use of UDP and 168 TCP transport, reducing the impact of problems associated with UDP 169 whilst constraining the impact of TCP on response times and server 170 resources to a manageable level. 172 The reduced overhead of this extension adds up significantly when 173 combined with other edns extensions, such as [CHAIN-QUERY] and 174 [STARTTLS]. For example, the combination of these EDNS extensions 175 make it possible for hosts on high-latency mobile networks to 176 natively perform DNSSEC validation and encrypt queries. 178 2. Requirements Notation 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 3. The edns-tcp-keepalive Option 186 This document specifies a new EDNS0 [RFC6891] option, edns-tcp- 187 keepalive, which can be used by DNS clients and servers to signal a 188 willingness to keep an idle TCP session open for a certain amount of 189 time to conduct future DNS transactions. This specification does not 190 distinguish between different types of DNS client and server in the 191 use of this option. 193 3.1. Option Format 195 The edns-tcp-keepalive option is encoded as follows: 197 1 2 3 198 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 199 +-------------------------------+-------------------------------+ 200 ! OPTION-CODE ! OPTION-LENGTH ! 201 +-------------------------------+-------------------------------+ 202 | TIMEOUT | 203 +---------------------------------------------------------------+ 205 where: 207 OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, 208 [TBD] 210 OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2 211 if it is present; 213 TIMEOUT: an idle timeout value for the TCP connection, specified in 214 units of 100 milliseconds, encoded in network byte order. 216 3.2. Use by DNS Clients 218 3.2.1. Sending Queries 220 DNS clients MUST NOT include the edns-tcp-keepalive option in queries 221 sent using UDP transport. 223 DNS clients MAY include the edns-tcp-keepalive option in the first 224 query sent to a server using TCP transport to signal their desire to 225 keep the connection open when idle. 227 Clients MUST specify a OPTION-LENGTH of 0 and omit the TIMEOUT value. 229 3.2.2. Receiving Responses 231 A DNS client that receives a response using UDP transport that 232 includes the edns-tcp-keepalive option MUST ignore the option. 234 A DNS client that receives a response using TCP transport that 235 includes the edns-tcp-keepalive option MAY keep the existing TCP 236 session open when it is idle. It SHOULD honour the timeout and 237 initiate close of the connection before the timeout expires. 239 A DNS client that receives a response that includes the edns-tcp- 240 keepalive option with a TIMEOUT value of 0 should send no more 241 queries on that connection and initiate closing the connection as 242 soon as it has received all outstanding responses. 244 A DNS client that sent a query containing the edns-keepalive-option 245 but receives a response that does not contain the edns-keepalive- 246 option should assume the server does not support keepalive and behave 247 following the guidance in [DRAFT-5966bis]. This holds true even if a 248 previous edns-keepalive-option exchange occurred on the existing TCP 249 connection. 251 3.3. Use by DNS Servers 253 3.3.1. Receiving Queries 255 A DNS server that receives a query using UDP transport that includes 256 the edns-tcp-keepalive option MUST ignore the option. 258 A DNS server that receives a query using TCP transport that includes 259 the edns-tcp-keepalive option MAY modify the local idle timeout 260 associated with that TCP session if resources permit. 262 3.3.2. Sending Responses 264 DNS servers MAY include the edns-tcp-keepalive option in responses 265 sent using TCP transport to signal their expected idle timeout on a 266 connection. Servers MUST specify the TIMEOUT value that is currently 267 associated with the TCP session. It is reasonable for this value to 268 change according to local resource constraints or in consideration of 269 intermediary behaviour (for example TCP middleboxes or NATs). The 270 DNS server SHOULD send a edns-tcp-keepalive option with a timeout of 271 0 if it deems its local resources are too low to service more TCP 272 keepalive sessions. 274 3.4. TCP Session Management 276 Both DNS clients and servers are subject to resource constraints 277 which will limit the extent to which TCP sessions can persist. 278 Effective limits for the number of active sessions that can be 279 maintained on individual clients and servers should be established, 280 either as configuration options or by interrogation of process limits 281 imposed by the operating system. Servers that implement keepalive 282 should also engage in TCP connection management by recycling existing 283 connections when appropriate, closing connections gracefully and 284 managing request queues to enable fair use. 286 In the event that there is greater demand for TCP sessions than can 287 be accommodated, servers may reduce the TIMEOUT value signalled in 288 successive DNS messages to minimise idle time on existing sessions. 290 This also allows, for example, clients with other candidate servers 291 to query to establish new TCP sessions with different servers in 292 expectation that an existing session is likely to be closed, or to 293 fall back to UDP. 295 Based on TCP session resources servers may signal a TIMEOUT value of 296 0 to request clients to close connections as soon as possible. This 297 is useful when server resources become very low or a denial-of- 298 service attack is detected and further maximises the shifting of 299 TIME_WAIT state to well-behaved clients. 301 However it should be noted that RCF6891 states: 303 Lack of presence of an OPT record in a request MUST be taken as an 304 indication that the requestor does not implement any part of this 305 specification and that the responder MUST NOT include an OPT 306 record in its response. 308 Since servers must be faithful to this specification even on a 309 persistent TCP connection it means that (following the initial 310 exchange of timeouts) a server may not be presented with the 311 opportunity to signal a change in the idle timeout associated with a 312 connection if the client does not send any further requests 313 containing EDNS0 OPT RRs. This limitation makes persistent 314 connection handling via an initial idle timeout signal more 315 attractive than a mechanism that establishes default persistence and 316 then uses a connection close signal (in a similar manner to HTTP 1.1 317 [RFC7320]). 319 DNS clients and servers MAY close a TCP session at any time in order 320 to manage local resource constraints. The algorithm by which clients 321 and servers rank active TCP sessions in order to determine which to 322 close is not specified in this document. 324 3.5. Non-Clean Paths 326 Many paths between DNS clients and servers suffer from poor hygiene, 327 limiting the free flow of DNS messages that include particular EDNS0 328 options, or messages that exceed a particular size. A fallback 329 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 330 be employed to avoid persistent interference due to non-clean paths. 332 3.6. Anycast Considerations 334 DNS servers of various types are commonly deployed using anycast 335 [RFC4786]. 337 Changes in network topology between clients and anycast servers may 338 cause disruption to TCP sessions making use of edns-tcp-keepalive 339 more often than with TCP sessions that omit it, since the TCP 340 sessions are expected to be longer-lived. Anycast servers MAY make 341 use of TCP multipath [RFC6824] to anchor the server side of the TCP 342 connection to an unambiguously-unicast address in order to avoid 343 disruption due to topology changes. 345 4. Intermediary Considerations 347 It is RECOMMENDED that DNS intermediaries which terminate TCP 348 connections implement keepalive. Should a non-keepalive-aware 349 intermediary sit between a client and server that both support 350 keepalive a potential side effect will be an increased frequency of 351 the proxy closing idle client connections. 353 5. Security Considerations 355 The edns-tcp-keep-alive option can potentially be abused to request 356 large numbers of sessions in a quick burst. When a Nameserver 357 detects abusive behaviour, it SHOULD immediately close the TCP 358 connection and free all buffers used. 360 Readers are advised to familiarise themselves with the security 361 considerations outlined in [DRAFT-5966bis] 363 This section needs more work. As usual. 365 6. IANA Considerations 367 The IANA is directed to assign an EDNS0 option code for the edns-tcp- 368 keepalive option from the DNS EDNS0 Option Codes (OPT) registry as 369 follows: 371 +-------+--------------------+----------+-----------------+ 372 | Value | Name | Status | Reference | 373 +-------+--------------------+----------+-----------------+ 374 | [TBA] | edns-tcp-keepalive | Optional | [This document] | 375 +-------+--------------------+----------+-----------------+ 377 7. Acknowledgements 379 The authors acknowledge the contributions of Jinmei TATUYA and Mark 380 Andrews. 382 8. References 384 8.1. Normative References 386 [RFC1035] Mockapetris, P., "Domain names - implementation and 387 specification", STD 13, RFC 1035, November 1987. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 393 Rose, "DNS Security Introduction and Requirements", RFC 394 4033, March 2005. 396 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 397 Services", BCP 126, RFC 4786, December 2006. 399 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 400 Requirements", RFC 5966, August 2010. 402 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 403 "TCP Extensions for Multipath Operation with Multiple 404 Addresses", RFC 6824, January 2013. 406 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 407 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 409 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 410 7320, July 2014. 412 8.2. Informative References 414 [CHAIN-QUERY] 415 Wouters, P., "Chain Query requests in DNS", draft-ietf- 416 dnsop-edns-chain-query (work in progress), October 2014. 418 [DRAFT-5966bis] 419 Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 420 D. Wessels, "DNS Transport over TCP - Implementation 421 Requirements", draft-ietf-dnsop-5966bis-02 (work in 422 progress), July 2015. 424 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 425 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012. 427 [STARTTLS] 428 Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 429 and P. Hoffman, "TLS for DNS: Initiation and Performance 430 Considerations", draft-ietf-dprive-start-tls-for-dns-02 431 (work in progress), May 2015. 433 Appendix A. Editors' Notes 435 A.1. Venue 437 An appropriate venue for discussion of this document is 438 dnsop@ietf.org. 440 A.2. Abridged Change History 442 A.2.1. draft-ietf-dnsop-edns-tcp-keepalive-02 444 Changed timeout value to idle timeout and re-phrased document around 445 this. 447 Changed units of timeout to 100ms to allow values less than 1 second. 449 Change specification to remove use of the option over UDP. This is 450 potentially confusing, could cause issues with ALG's and adds only 451 limited value. 453 Changed semantics so the client no longer sends a timeout. The 454 client timeout is of limited value as servers should be managing 455 connections based on their view of their resources, not on client 456 requests as this is open to abuse. Additionally this identifies 457 cases were the option is simply being reflected back. 459 Changed semantics for the meaning of a server sending a timeout of 0. 460 The maximum timeout value of 6553.5s (~1.8h) is already large and a 461 distinct 'connection close'-like signal is potentially more useful. 463 Added more detail on server side requirements when supporting 464 keepalive in terms of resource and connection management. 466 Added discussion of EDNS0 per-message limitation and implications of 467 this. 469 Added reference to STARTTLS draft and RFC7320. 471 A.2.2. draft-ietf-dnsop-edns-tcp-keepalive-01 473 Version bump with no changes 475 A.2.3. draft-ietf-dnsop-edns-tcp-keepalive-00 477 Clarifications, working group adoption. 479 A.2.4. draft-wouters-edns-tcp-keepalive-01 481 Also allow clients to specify KEEPALIVE timeout values, clarify 482 motivation of document. 484 A.2.5. draft-wouters-edns-tcp-keepalive-00 486 Initial draft. 488 Authors' Addresses 490 Paul Wouters 491 Red Hat 493 Email: pwouters@redhat.com 495 Joe Abley 496 Dyn, Inc. 497 470 Moore Street 498 London, ON N6C 2C2 499 Canada 501 Phone: +1 519 670 9327 502 Email: jabley@dyn.com 504 Sara Dickinson 505 Sinodun Internet Technologies 506 Magdalen Centre 507 Oxford Science Park 508 Oxford OX4 4GA 509 UK 511 Email: sara@sinodun.com 512 URI: http://sinodun.com 513 Ray Bellis 514 Internet Systems Consortium, Inc 515 950 Charter Street 516 Redwood City CA 94063 517 USA 519 Phone: +1 650 423 1200 520 Email: ray@isc.org 521 URI: http://www.isc.org