idnits 2.17.1 draft-wouters-edns-tcp-keepalive-00.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 15, 2013) is 3840 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 194, but not defined == Missing Reference: 'TBA' is mentioned on line 336, but not defined ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 3 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: April 18, 2014 Dyn Inc. 6 October 15, 2013 8 The edns-tcp-keepalive EDNS0 Option 9 draft-wouters-edns-tcp-keepalive-00 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 most implementations 19 limit the TCP session to a single DNS query and answer, making use of 20 TCP only suitable as a fallback protocol for UDP. 22 This document defines an EDNS0 option ("edns-tcp-keepalive") that 23 allows DNS clients and servers to signal their respective readiness 24 to conduct multiple DNS transactions over individual TCP sessions. 25 This signalling facilitates a better balance of UDP and TCP transport 26 between individual clients and servers, reducing the impact of 27 problems associated with UDP transport and allowing the state 28 associated with TCP transport to be managed effectively with minimal 29 impact on the DNS transaction time. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 18, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 67 3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 4 68 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5 70 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5 71 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 5 72 3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6 73 3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6 74 3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6 75 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 6 76 3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 7 77 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 7 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 83 7.2. Informative References . . . . . . . . . . . . . . . . . 9 84 Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 9 85 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 A.2. Abridged Change History . . . . . . . . . . . . . . . . . 9 87 A.2.1. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 DNS messages between clients and servers may be received over either 93 UDP or TCP [RFC1035]. Generally, DNS clients prefer to send queries 94 over UDP, and fall back to TCP only if a query over UDP resulted in a 95 truncated response (see [RFC1035] Section 4.1.1). A client that has 96 resorted to TCP transport as a reaction to a truncated response from 97 a server typically closes the session after exchanging a single 98 (request, response) DNS message pair, and continues with UDP 99 transport for subsequent queries. Although [RFC1035] specifies that 100 a single TCP session may be used to exchange multiple DNS messages, 101 in practice this is rarely seen. 103 UDP transport is stateless, and hence presents a much lower resource 104 burden on a busy DNS server than TCP. An exchange of DNS messages 105 over UDP can also be completed in a single round trip between 106 communicating hosts, resulting in optimally-short transaction times. 107 UDP transport is not without its risks, however. 109 A single-datagram exchange over UDP between two hosts can be 110 exploited to enable a reflection attack on a third party. Mitigation 111 of such attacks on authoritative-only servers is possible using an 112 approach known as Response Rate-Limiting [RRL], an approach designed 113 to minimise the frequency at which legitimate responses are discarded 114 by truncating responses that appear to be motivated by an attacker, 115 forcing legitimate clients to re-query using TCP transport. 117 [RFC1035] specified a maximum DNS message size over UDP transport of 118 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols 119 subsequently increased the observed frequency at which responses 120 exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than 121 512 bytes to be exchanged over UDP, with a corresponding increased 122 incidence of fragmentation. Fragmentation is known to be problematic 123 in general, and has also been implicated in increasing the risk of 124 cache poisoning attacks. 126 The use of TCP transport does not suffer from the risks of 127 fragmentation nor reflection attacks. However, TCP transport as 128 currently deployed has expensive overhead. 130 The overhead of the three-way TCP handshake for a single DNS 131 transaction is substantial, increasing the transaction time for a 132 single (request, response) pair of DNS messages from 1 x RTT to 2 x 133 RTT. There is no such overhead for a session that is already 134 established, however, and the overall impact of the TCP setup 135 handshake when the resulting session is used to exchange N DNS 136 message pairs over a single session, (1 + N)/N, approaches unity as N 137 increases. 139 (It should perhaps be noted that the overhead for a DNS transaction 140 over UDP truncacated due to RRL is 3x RTT, higher than the overhead 141 imposed on the same transaction initiated over TCP.) 142 With increased deployment of DNSSEC and new RRtypes containing 143 application specific cryptographic material, there is an increase in 144 UDP truncation with fallback to TCP. 146 The use of TCP transport requires considerably more state to be 147 retained on DNS servers. If a server is to perform adequately with a 148 significant query load received over TCP, it must manage its 149 available resources to ensure that all established TCP sessions are 150 well-used, and that those which are unlikely to be used for the 151 exchange of multiple DNS messages are closed promptly. 153 This document proposes a signalling mechanism between DNS clients and 154 servers that provides a means for servers to better balance the use 155 of UDP and TCP transport, reducing the impact of problems associated 156 with UDP whilst constraining the impact of TCP on response times and 157 server resources to a manageable level. 159 The reduced overhead of this extension adds up significantly when 160 combined with other edns extensions, such as [CHAIN-QUERY]. The 161 combination of these two EDNS extensions make it possible for hosts 162 on high-latency mobile networks to natively perform DNSSEC 163 validation. 165 2. Requirements Notation 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 3. The edns-tcp-keepalive Option 173 This document specifies a new EDNS0 [RFC6891] option, edns-tcp- 174 keepalive, which can be used by DNS clients and servers to signal a 175 willingness to conduct multiple DNS transactions over a single TCP 176 session. This specification does not distinguish between different 177 types of DNS client and server in the use of this option. 179 3.1. Option Format 181 The edns-tcp-keepalive option is encoded as follows: 183 1 2 3 184 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 185 +-------------------------------+-------------------------------+ 186 ! OPTION-CODE ! OPTION-LENGTH ! 187 +-------------------------------+-------------------------------+ 188 | TIMEOUT | 189 +---------------------------------------------------------------+ 191 where: 193 OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, 194 [TBD] 196 OPTION-LENGTH: the value 2; 198 TIMEOUT: a timeout value for the TCP connection specified by DNS 199 servers, specified in seconds, encoded in network byte order. DNS 200 clients set this value to 0. 202 3.2. Use by DNS Clients 204 3.2.1. Sending Queries 206 DNS clients MAY include the edns-tcp-keepalive option in queries sent 207 using UDP transport to signal their general ability to use individual 208 TCP sessions for multiple DNS transactions with a particular server. 210 DNS clients MAY include the edns-tcp-keepalive option in the first 211 query sent to a server using TCP transport to signal their desire 212 that that specific TCP session be used for multiple DNS transactions. 214 DNS Clients MUST specify a TIMEOUT value of zero. 216 3.2.2. Receiving Responses 218 A DNS client that receives a response using UDP transport that 219 includes the edns-tcp-keepalive option MAY record the presence of the 220 option and the associated TIMEOUT value, and use that information as 221 part of its server selection algorithm in the case where multiple 222 candidate servers are available to service a particular query. 224 A DNS client that receives a response using TCP transport that 225 includes the edns-tcp-keepalive option MAY keep the existing TCP 226 session open. 228 A DNS client that receives a response that includes the edns-tcp- 229 keepalive option with a TIMEOUT value of 0 is allowed to keep the TCP 230 connection open indefinately. 232 3.3. Use by DNS Servers 234 3.3.1. Receiving Queries 236 A DNS server that receives a query using UDP transport that includes 237 the edns-tcp-keepalive option MAY record the presence of the option 238 for statistical purposes, but should not otherwise modify its usual 239 behaviour in sending a response. 241 A DNS server that receives a query that includes the edns-tcp- 242 keepalive option MUST ignore the TIMEOUT value 244 3.3.2. Sending Responses 246 DNS servers MAY include the edns-tcp-keepalive option in responses 247 sent using UDP transport to signal their general ability to use 248 individual TCP sessions for multiple DNS transactions with a 249 particular server. The TIMEOUT value should be indicative of what a 250 client might expect if it was to open a TCP session with the server 251 and receive a response with the edns-tcp-keepalive option present. 252 The DNS server MAY omit including the edns-tcp-keepalive option if it 253 is running too low on resources to service more TCP keepalive 254 sessions. 256 DNS servers MAY include the edns-tcp-keepalive option in responses 257 sent using TCP transport to signal their ability to use that specific 258 session to exchange multiple DNS transactions. Servers MUST specify 259 the TIMEOUT value that is currently associated with the TCP session. 260 It is reasonable for this value to change according to local resource 261 constraints. The DNS server MAY omit including the edns-tcp- 262 keepalive option if it deems its local resources are too low to 263 service more TCP keepalive sessions. 265 3.4. TCP Session Management 267 Both DNS clients and servers are subject to resource constraints 268 which will limit the extent to which TCP sessions can persist. 269 Effective limits for the number of active sessions that can be 270 maintained on individual clients and servers should be established, 271 either as configuration options or by interrogation of process limits 272 imposed by the operating system. 274 In the event that there is greater demand for TCP sessions than can 275 be accommodated, servers may reduce the TIMEOUT value signalled in 276 successive DNS messages to avoid abrupt termination of a session. 277 This allows, for example, clients with other candidate servers to 278 query to establish new TCP sessions with different servers in 279 expectation that an existing session is likely to be closed, or to 280 fall back to UDP. 282 DNS clients and servers MAY close a TCP session at any time in order 283 to manage local resource constraints. The algorithm by which clients 284 and servers rank active TCP sessions in order to determine which to 285 close is not specified in this document. 287 3.5. Non-Clean Paths 289 Many paths between DNS clients and servers suffer from poor hygiene, 290 limiting the free flow of DNS messages that include particular EDNS0 291 options, or messages that exceed a particular size. A fallback 292 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 293 be employed to avoid persistent interference due to non-clean paths. 295 3.6. Anycast Considerations 297 DNS servers of various types are commonly deployed using anycast 298 [RFC4786]. 300 Successive DNS transactions between a client and server using UDP 301 transport may involve responses generated by different anycast nodes, 302 and the use of anycast in the implementation of a DNS server is 303 effectively undetectable by the client. The edns-tcp-keepalive 304 option SHOULD NOT be included in responses using UDP transport from 305 servers provisioned using anycast unless all anycast server nodes are 306 capable of processing the edns-tcp-keepalive option. The TIMEOUT 307 values in UDP responses from anycast servers MUST be zero to indicate 308 that there is no useful value that can be specified. 310 Changes in network topology between clients and anycast servers may 311 cause disruption to TCP sessions making use of edns-tcp-keepalive 312 more often than with TCP sessions that omit it, since the TCP 313 sessions are expected to be longer-lived. Anycast servers MAY make 314 use of TCP multipath [RFC6824] to anchor the server side of the TCP 315 connection to an unambiguously-unicast address in order to avoid 316 disruption due to topology changes. 318 4. Security Considerations 320 The edns-tcp-keep-alive option can potentially be abused to request 321 large numbers of sessions in a quick burst. When a Nameserver 322 detects abusive behaviour, it SHOULD immediately close the TCP 323 connection and free all buffers used. 325 This section needs more work. As usual. 327 5. IANA Considerations 329 The IANA is directed to assign an EDNS0 option code for the edns-tcp- 330 keepalive option from the DNS EDNS0 Option Codes (OPT) registry as 331 follows: 333 +-------+--------------------+----------+-----------------+ 334 | Value | Name | Status | Reference | 335 +-------+--------------------+----------+-----------------+ 336 | [TBA] | edns-tcp-keepalive | Optional | [This document] | 337 +-------+--------------------+----------+-----------------+ 339 6. Acknowledgements 341 empty for now 343 7. References 345 7.1. Normative References 347 [CHAIN-QUERY] 348 Wouters, P., "TCP chain query requests in DNS", draft- 349 wouters-edns-tcp-chain-query (work in progress), October 350 2013. 352 [RFC1035] Mockapetris, P., "Domain names - implementation and 353 specification", STD 13, RFC 1035, November 1987. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 359 Rose, "DNS Security Introduction and Requirements", RFC 360 4033, March 2005. 362 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 363 Services", BCP 126, RFC 4786, December 2006. 365 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 366 "TCP Extensions for Multipath Operation with Multiple 367 Addresses", RFC 6824, January 2013. 369 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 370 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 372 7.2. Informative References 374 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 375 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012. 377 Appendix A. Editors' Notes 379 A.1. Venue 381 An appropriate venue for discussion of this document is 382 dnsext@ietf.org. 384 A.2. Abridged Change History 386 A.2.1. draft-wouters-edns-tcp-keepalive-00 388 Initial draft. 390 Authors' Addresses 392 Paul Wouters 393 Red Hat 395 Email: pwouters@redhat.com 397 Joe Abley 398 Dyn Inc. 399 470 Moore Street 400 London, ON N6C 2C2 401 Canada 403 Phone: +1 519 670 9327 404 Email: jabley@dyn.com