idnits 2.17.1 draft-wouters-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 (February 14, 2014) is 3717 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 199, but not defined == Missing Reference: 'TBA' is mentioned on line 350, but not defined == Unused Reference: 'RFC5966' is defined on line 379, 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) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track J. Abley 5 Expires: August 18, 2014 Dyn, Inc. 6 February 14, 2014 8 The edns-tcp-keepalive EDNS0 Option 9 draft-wouters-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 August 18, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5 71 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5 72 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 5 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-wouters-edns-tcp-keepalive-00 . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 DNS messages between clients and servers may be received over either 94 UDP or TCP [RFC1035]. Historically, DNS clients used API's that only 95 facilitated sending and receiving a single query over either UDP or 96 TCP. New APIs and deployment of DNSSEC validating resolvers on hosts 97 that in the past were using stub resolving only is increasing the DNS 98 client base that prefer using long lived TCP connections. Long-lived 99 TCP connections can result in lower request latency than the case 100 where UDP transport is used and truncated responses are received, 101 since clients that have fallen back to TCP transport in response to a 102 truncated response typically only uses the TCP session for a single 103 (request, response) pair, continuing with UDP transport for 104 subsequent queries. 106 UDP transport is stateless, and hence presents a much lower resource 107 burden on a busy DNS server than TCP. An exchange of DNS messages 108 over UDP can also be completed in a single round trip between 109 communicating hosts, resulting in optimally-short transaction times. 110 UDP transport is not without its risks, however. 112 A single-datagram exchange over UDP between two hosts can be 113 exploited to enable a reflection attack on a third party. Mitigation 114 of such attacks on authoritative-only servers is possible using an 115 approach known as Response Rate-Limiting [RRL], an approach designed 116 to minimise the frequency at which legitimate responses are discarded 117 by truncating responses that appear to be motivated by an attacker, 118 forcing legitimate clients to re-query using TCP transport. 120 [RFC1035] specified a maximum DNS message size over UDP transport of 121 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols 122 subsequently increased the observed frequency at which responses 123 exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than 124 512 bytes to be exchanged over UDP, with a corresponding increased 125 incidence of fragmentation. Fragmentation is known to be problematic 126 in general, and has also been implicated in increasing the risk of 127 cache poisoning attacks. 129 The use of TCP transport does not suffer from the risks of 130 fragmentation nor reflection attacks. However, TCP transport as 131 currently deployed has expensive overhead. 133 The overhead of the three-way TCP handshake for a single DNS 134 transaction is substantial, increasing the transaction time for a 135 single (request, response) pair of DNS messages from 1 x RTT to 2 x 136 RTT. There is no such overhead for a session that is already 137 established, however, and the overall impact of the TCP setup 138 handshake when the resulting session is used to exchange N DNS 139 message pairs over a single session, (1 + N)/N, approaches unity as N 140 increases. 142 (It should perhaps be noted that the overhead for a DNS transaction 143 over UDP truncacated due to RRL is 3x RTT, higher than the overhead 144 imposed on the same transaction initiated over TCP.) 145 With increased deployment of DNSSEC and new RRtypes containing 146 application specific cryptographic material, there is an increase in 147 the prevalence of truncated responses received over UDP with fallback 148 to TCP. 150 The use of TCP transport requires considerably more state to be 151 retained on DNS servers. If a server is to perform adequately with a 152 significant query load received over TCP, it must manage its 153 available resources to ensure that all established TCP sessions are 154 well-used, and that those which are unlikely to be used for the 155 exchange of multiple DNS messages are closed promptly. 157 This document proposes a signalling mechanism between DNS clients and 158 servers that provides a means to better balance the use of UDP and 159 TCP transport, reducing the impact of problems associated with UDP 160 whilst constraining the impact of TCP on response times and server 161 resources to a manageable level. 163 The reduced overhead of this extension adds up significantly when 164 combined with other edns extensions, such as [CHAIN-QUERY]. The 165 combination of these two EDNS extensions make it possible for hosts 166 on high-latency mobile networks to natively perform DNSSEC 167 validation. 169 2. Requirements Notation 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 3. The edns-tcp-keepalive Option 177 This document specifies a new EDNS0 [RFC6891] option, edns-tcp- 178 keepalive, which can be used by DNS clients and servers to signal a 179 willingness to keep an (idle) TCP session open for a certain amount 180 of time to conduct future DNS transactions. This specification does 181 not distinguish between different types of DNS client and server in 182 the use of this option. 184 3.1. Option Format 186 The edns-tcp-keepalive option is encoded as follows: 188 1 2 3 189 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 190 +-------------------------------+-------------------------------+ 191 ! OPTION-CODE ! OPTION-LENGTH ! 192 +-------------------------------+-------------------------------+ 193 | TIMEOUT | 194 +---------------------------------------------------------------+ 196 where: 198 OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, 199 [TBD] 201 OPTION-LENGTH: the value 2; 203 TIMEOUT: a timeout value for the TCP connection, specified in 204 seconds, encoded in network byte order. 206 3.2. Use by DNS Clients 208 3.2.1. Sending Queries 210 DNS clients MAY include the edns-tcp-keepalive option in queries sent 211 using UDP transport to signal their general ability to use individual 212 TCP sessions for multiple DNS transactions with a particular server. 214 DNS clients MAY include the edns-tcp-keepalive option in the first 215 query sent to a server using TCP transport to signal their desire 216 that that specific TCP session be used for multiple DNS transactions. 218 Clients MAY specify a TIMEOUT value that is representative of the 219 minimum expected time an individual TCP session should remain 220 established for it to be used by multiple DNS transactions. 222 In the case where there are multiple candidate servers available to 223 service a particular transaction, clients MAY include data associated 224 with all servers when computing a TIMEOUT value to be signalled to 225 any one of those servers. 227 If the client has insufficient data to be able to provide a 228 meaningful estimate, the TIMEOUT value MUST be set to zero. 230 3.2.2. Receiving Responses 232 A DNS client that receives a response using UDP transport that 233 includes the edns-tcp-keepalive option MAY record the presence of the 234 option and the associated TIMEOUT value, and use that information as 235 part of its server selection algorithm in the case where multiple 236 candidate servers are available to service a particular query. 238 A DNS client that receives a response using TCP transport that 239 includes the edns-tcp-keepalive option MAY keep the existing TCP 240 session open. 242 A DNS client that receives a response that includes the edns-tcp- 243 keepalive option with a TIMEOUT value of 0 is allowed to keep the TCP 244 connection open indefinately. 246 3.3. Use by DNS Servers 248 3.3.1. Receiving Queries 250 A DNS server that receives a query using UDP transport that includes 251 the edns-tcp-keepalive option MAY record the presence of the option 252 for statistical purposes, but should not otherwise modify its usual 253 behaviour in sending a response. 255 A DNS server that receives a query using TCP transport that includes 256 the edns-tcp-keepalive option SHOULD extend the timeout normally 257 associated with TCP sessions if resources permit, using the TIMEOUT 258 value supplied by the client as a guide. 260 3.3.2. Sending Responses 262 DNS servers MAY include the edns-tcp-keepalive option in responses 263 sent using UDP transport to signal their general ability to use 264 individual TCP sessions for multiple DNS transactions with a 265 particular server. The TIMEOUT value should be indicative of what a 266 client might expect if it was to open a TCP session with the server 267 and receive a response with the edns-tcp-keepalive option present. 268 The DNS server MAY omit including the edns-tcp-keepalive option if it 269 is running too low on resources to service more TCP keepalive 270 sessions. 272 DNS servers MAY include the edns-tcp-keepalive option in responses 273 sent using TCP transport to signal their ability to use that specific 274 session to exchange multiple DNS transactions. Servers MUST specify 275 the TIMEOUT value that is currently associated with the TCP session. 276 It is reasonable for this value to change according to local resource 277 constraints. The DNS server MAY omit including the edns-tcp- 278 keepalive option if it deems its local resources are too low to 279 service more TCP keepalive sessions. 281 3.4. TCP Session Management 283 Both DNS clients and servers are subject to resource constraints 284 which will limit the extent to which TCP sessions can persist. 285 Effective limits for the number of active sessions that can be 286 maintained on individual clients and servers should be established, 287 either as configuration options or by interrogation of process limits 288 imposed by the operating system. 290 In the event that there is greater demand for TCP sessions than can 291 be accommodated, servers may reduce the TIMEOUT value signalled in 292 successive DNS messages to avoid abrupt termination of a session. 293 This allows, for example, clients with other candidate servers to 294 query to establish new TCP sessions with different servers in 295 expectation that an existing session is likely to be closed, or to 296 fall back to UDP. 298 DNS clients and servers MAY close a TCP session at any time in order 299 to manage local resource constraints. The algorithm by which clients 300 and servers rank active TCP sessions in order to determine which to 301 close is not specified in this document. 303 3.5. Non-Clean Paths 305 Many paths between DNS clients and servers suffer from poor hygiene, 306 limiting the free flow of DNS messages that include particular EDNS0 307 options, or messages that exceed a particular size. A fallback 308 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 309 be employed to avoid persistent interference due to non-clean paths. 311 3.6. Anycast Considerations 313 DNS servers of various types are commonly deployed using anycast 314 [RFC4786]. 316 Successive DNS transactions between a client and server using UDP 317 transport may involve responses generated by different anycast nodes, 318 and the use of anycast in the implementation of a DNS server is 319 effectively undetectable by the client. The edns-tcp-keepalive 320 option SHOULD NOT be included in responses using UDP transport from 321 servers provisioned using anycast unless all anycast server nodes are 322 capable of processing the edns-tcp-keepalive option. 324 Changes in network topology between clients and anycast servers may 325 cause disruption to TCP sessions making use of edns-tcp-keepalive 326 more often than with TCP sessions that omit it, since the TCP 327 sessions are expected to be longer-lived. Anycast servers MAY make 328 use of TCP multipath [RFC6824] to anchor the server side of the TCP 329 connection to an unambiguously-unicast address in order to avoid 330 disruption due to topology changes. 332 4. Security Considerations 334 The edns-tcp-keep-alive option can potentially be abused to request 335 large numbers of sessions in a quick burst. When a Nameserver 336 detects abusive behaviour, it SHOULD immediately close the TCP 337 connection and free all buffers used. 339 This section needs more work. As usual. 341 5. IANA Considerations 343 The IANA is directed to assign an EDNS0 option code for the edns-tcp- 344 keepalive option from the DNS EDNS0 Option Codes (OPT) registry as 345 follows: 347 +-------+--------------------+----------+-----------------+ 348 | Value | Name | Status | Reference | 349 +-------+--------------------+----------+-----------------+ 350 | [TBA] | edns-tcp-keepalive | Optional | [This document] | 351 +-------+--------------------+----------+-----------------+ 353 6. Acknowledgements 355 The authors acknowledge the contributions of Ray Bellis, Jinmei 356 TATUYA and Mark Andrews. 358 7. References 360 7.1. Normative References 362 [CHAIN-QUERY] 363 Wouters, P., "chain Query requests in DNS", draft-wouters- 364 edns-chain-query (work in progress), February 2014. 366 [RFC1035] Mockapetris, P., "Domain names - implementation and 367 specification", STD 13, RFC 1035, November 1987. 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 373 Rose, "DNS Security Introduction and Requirements", RFC 374 4033, March 2005. 376 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 377 Services", BCP 126, RFC 4786, December 2006. 379 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 380 Requirements", RFC 5966, August 2010. 382 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 383 "TCP Extensions for Multipath Operation with Multiple 384 Addresses", RFC 6824, January 2013. 386 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 387 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 389 7.2. Informative References 391 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 392 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012. 394 Appendix A. Editors' Notes 396 A.1. Venue 398 An appropriate venue for discussion of this document is 399 dnsext@ietf.org. 401 A.2. Abridged Change History 403 A.2.1. draft-wouters-edns-tcp-keepalive-00 405 Initial draft. 407 Authors' Addresses 409 Paul Wouters 410 Red Hat 412 Email: pwouters@redhat.com 414 Joe Abley 415 Dyn, Inc. 416 470 Moore Street 417 London, ON N6C 2C2 418 Canada 420 Phone: +1 519 670 9327 421 Email: jabley@dyn.com