idnits 2.17.00 (12 Aug 2021) /tmp/idnits28364/draft-eastlake-dnsext-cookies-04.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 22, 2014) is 3040 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) ** Downref: Normative reference to an Informational draft: draft-eastlake-fnv (ref. 'FNV') -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended Status: Proposed Standard Huawei 3 Expires: July 21, 2014 January 22, 2014 5 Domain Name System (DNS) Cookies 6 8 Abstract 10 DNS cookies are a lightweight DNS transaction security mechanism 11 designed for incremental deployment. They provide limited protection 12 to DNS servers and resolvers against a variety of increasingly common 13 denial-of-service and amplification/forgery or cache poisoning 14 attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT- 15 PT, and anycast. 17 Status of This Document 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Distribution of this document is unlimited. Comments should be sent 23 to the author or the DNSEXT mailing list . 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 37 Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction............................................3 43 1.1 Contents of This Document..............................3 44 1.2 Definitions............................................4 46 2. Threats Considered......................................5 47 2.1 Denial-of-Service Attacks..............................5 48 2.1.1 DNS Amplification Attacks............................5 49 2.1.2 DNS Server Denial-of-Service.........................5 50 2.2 Cache Poisoning and Answer Forgery Attacks.............6 52 3. Comments on Existing DNS Security.......................7 53 3.1 Existing DNS Data Security.............................7 54 3.2 DNS Message/Transaction Security.......................7 55 3.3 Conclusions on Existing DNS Security...................7 57 4. The COOKIE OPT Option...................................8 58 4.1 Resolver Cookie........................................8 59 4.2 Server Cookie..........................................9 60 4.3 Error Code.............................................9 62 5. DNS Cookies Protocol Description.......................11 63 5.1 Originating Requests..................................11 64 5.2 Responding to Requests................................11 65 5.3 Processing Responses..................................11 67 6. DNS Cookie Policies and Implementation.................13 68 6.1 Resolver Policies and Implementation..................13 69 6.2 Server Policies and Implementation....................14 70 6.3 Resolver and Server Secret Rollover...................15 71 6.4 Implementation Requirement............................15 73 7. NAT Considerations and AnyCast Server Considerations...17 74 8. Deployment.............................................19 75 9. IANA Considerations....................................20 77 10. Security Considerations...............................21 78 10.1 Cookie Algorithm Considerations......................21 80 Acknowledgements..........................................22 81 Normative References......................................23 82 Informative References....................................23 83 Author's Address..........................................25 85 1. Introduction 87 As with many core Internet protocols, the Domain Name System (DNS) 88 was originally designed at a time when the Internet had only a small 89 pool of trusted users. As the Internet has grown exponentially to a 90 global information utility, the DNS has increasingly been subject to 91 abuse. 93 This document describes DNS cookies, a lightweight DNS transaction 94 security mechanism specified as an OPT [RFC6891] option. This 95 mechanism provides limited protection to DNS servers and resolvers 96 against a variety of increasingly common abuses by off-path 97 attackers. 99 The DNS cookies mechanism has a default mode that supports 100 incremental deployment. If only one party to a DNS transaction 101 supports the mechanism, it does not provide a benefit or 102 significantly interfere, but, if both support it, the additional 103 security provided is automatically available. 105 The DNS cookies mechanism is compatible with and can be used in 106 conjunction with other DNS transaction forgery resistance measures 107 such as those in [RFC5452]. 109 The DNS cookies mechanism is designed to work in the presence of NAT 110 and NAT-PT boxes and guidance is provided herein on supporting the 111 DNS cookies mechanism in anycast servers. 113 1.1 Contents of This Document 115 In Section 2, we discuss the threats against which the DNS cookie 116 mechanism provides some protection. 118 Section 3 describes existing DNS security mechanisms and why they are 119 not adequate substitutes for DNS cookies. 121 Section 4 describes the COOKIE OPT option and Section 5 provides a 122 protocol description including suggestions for calculating Resolver 123 and Server Cookies. 125 Section 6 gives further details on the processing of COOKIE OPT 126 options by resolvers and server and policies for such processing. 128 Section 7 discusses some NAT and anycast related DNS Cookies design 129 considerations. 131 Section 8 discusses incremental deployment considerations. 133 Sections 9 and 10 describe IANA and Security Considerations. 135 1.2 Definitions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 An "off-path attacker", for a particular DNS resolver and server, is 142 defined as an attacker who cannot observe the plain text of DNS 143 requests and responses between that resolver and server. 145 "Soft state" indicates information learned or derived by a host which 146 may be discarded when indicated by the policies of that host but can 147 be later re-instantiated if needed. For example, it could be 148 discarded after a period of time or when storage for caching such 149 data becomes full. If operations requiring that soft state continue 150 after it has been discarded, it will be automatically re-generated, 151 albeit at some cost. 153 "Silently discarded" indicates that there are no DNS protocol message 154 consequences; however, it is RECOMMENDED that appropriate network 155 management facilities be included in implementations, such as a 156 counter of the occurrences of each type of such events. 158 The term "IP address" is used herein in a length independent manner 159 and refers to both IPv4 and IPv6. 161 2. Threats Considered 163 DNS cookies are intended to provide significant but limited 164 protection against certain attacks by off-path attackers as described 165 below. These attacks include denial-of-service, cache poisoning and 166 answer forgery. 168 2.1 Denial-of-Service Attacks 170 The typical form of the denial-of-service attacks considered herein 171 is to send DNS requests with forged source IP addresses to a server. 172 The intent can be to attack that server or some other selected host 173 as described below. 175 2.1.1 DNS Amplification Attacks 177 A request with a forged IP address generally causes a response to be 178 sent to that forged IP address. Thus the forging of many such 179 requests with a particular source IP address can result in enough 180 traffic being sent to the forged IP address to interfere with service 181 to the host at the IP address. Furthermore, it is generally easy in 182 the DNS to create short requests that produce much longer responses, 183 thus amplifying the attack. 185 The DNS Cookies mechanism can severely limit the traffic 186 amplification obtained by attackers off path for the server and the 187 attacked host. Enforced DNS cookies would make it hard for an off 188 path attacker to cause any more than rate-limited short error 189 responses to be sent to a forged IP address so the attack would be 190 reduced rather than amplified. DNS cookies make it more effective to 191 implement a rate limiting scheme for bad DNS cookie error responses 192 from the server. Such a scheme would further restrict selected host 193 denial-of-service traffic from that server. 195 2.1.2 DNS Server Denial-of-Service 197 DNS requests that are accepted cause work on the part of DNS servers. 198 This is particularly true for recursive servers that may issue one or 199 more requests and process the responses thereto, in order to 200 determine their response to the initial request. And the situation 201 can be even worse for recursive servers implementing DNSSEC 202 ([RFC4033] [RFC4034] [RFC4035]) because they may be induced to 203 perform burdensome public key cryptographic computations in attempts 204 to verify the authenticity of data they retrieve in trying to answer 205 the request. 207 The computational or communications burden caused by such requests 208 may not dependent on a forged IP source address, but the use of such 209 addresses makes 210 + the source of the requests causing the denial-of-service attack 211 harder to find and 212 + restriction of the IP addresses from which such requests should 213 be honored hard or impossible to specify or verify. 215 Use of DNS cookies should enables a server to reject forged queries 216 from an off path attacker with relative ease and before any recursive 217 queries or public key cryptographic operations are performed. 219 2.2 Cache Poisoning and Answer Forgery Attacks 221 The form of the cache poisoning attacks considered is to send forged 222 replies to a resolver. Modern network speeds for well-connected hosts 223 are such that, by forging replies from the IP addresses of heavily 224 used DNS servers for popular names to a heavily used resolver, there 225 can be an unacceptably high probability of randomly coming up with a 226 reply that will be accepted and cause false DNS information to be 227 cached by that resolver (the Dan Kaminsky attack). This can be used 228 to facilitate phishing attacks and other diversion of legitimate 229 traffic to a compromised or malicious host such as a web server. 231 With the use of DNS cookies, a resolver can generally reject such 232 forged replies. 234 3. Comments on Existing DNS Security 236 Two forms of security have been added to DNS, data security and 237 message/transaction security. 239 3.1 Existing DNS Data Security 241 DNS data security is one part of DNSSEC and is described in 242 [RFC4033], [RFC4034], and [RFC4035] and updates thereto. It provides 243 data origin authentication and authenticated denial of existence. 244 DNSSEC is being deployed and can provide strong protection against 245 forged data; however, it has the unintended effect of making some 246 denial-of-service attacks worse because of the cryptographic 247 computational load it can require and the increased size in DNS 248 packets that it tends to produce. 250 3.2 DNS Message/Transaction Security 252 The second form of security that has been added to DNS provides 253 "transaction" security through TSIG [RFC2845] or SIG(0) [RFC2931]. 254 TSIG could provide strong protection against the attacks for which 255 the DNS Cookies mechanism provide weak protection; however, TSIG is 256 non-trivial to deploy in the general Internet because of the burden 257 it imposes of pre-agreement and key distribution between resolver- 258 server pairs, the burden of server side key state, and because it 259 requires time synchronization between resolver and server. 261 TKEY [RFC2930] can solve the problem of key distribution for TSIG but 262 some modes of TKEY impose a substantial cryptographic computation 263 loads and can be dependent on the deployment of DNS data security 264 (see Section 3.1). 266 SIG(0) [RFC2931] provides less denial of service protection than TSIG 267 or, in one way, even DNS cookies, because it does not authenticate 268 requests, only complete transactions. In any case, it also depends 269 on the deployment of DNS data security and requires computationally 270 burdensome public key cryptographic operations. 272 3.3 Conclusions on Existing DNS Security 274 The existing DNS security mechanisms do not provide the services 275 provided by the DNS Cookies mechanism: lightweight message 276 authentication of DNS requests and responses with no requirement for 277 pre-configuration or server side state. 279 4. The COOKIE OPT Option 281 COOKIE is an OPT RR [RFC6891] option that can be included no more 282 than once in the RDATA portion of an OPT RR in DNS requests and 283 responses. 285 The option is encoded into 22 bytes as shown below. 287 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | OPTION-CODE = {TBD} | OPTION-LENGTH = 18 | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 +- Resolver Cookie -+ 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 +- Server Cookie -+ 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Error Code | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 The 64-bit Resolver and Server Cookies are stored in little endian 304 order and are determined as described below. 306 4.1 Resolver Cookie 308 The Resolver Cookie SHOULD be a pseudo-random function of the server 309 IP address and a secret quantity known only to the resolver. This 310 resolver secret SHOULD have at least 64 bits of entropy [RFC4086bis] 311 and be changed periodically (see Section 6.3). The selection of the 312 pseudo-random function is a private matter to the resolver as only 313 the resolver needs to recognize its own DNS cookies. An example 314 method is the FNV-64 [FNV] of the server IP address and the resolver 315 secret. That is 317 Resolver Cookie = FNV-64 ( Resolver Secret | Server IP Address ) 319 where "|" indicates concatenation. 321 A resolver MUST NOT use the same Resolver Cookie value for queries to 322 all servers. 324 4.2 Server Cookie 326 The Server Cookie SHOULD be a pseudo-random function of the request 327 source IP address, the request Resolver Cookie, and a secret quantity 328 known only to the server. (See Section 7 for a discussion of why the 329 Resolver Cookie is used as input to the Server Cookie but the Server 330 Cookie is not used as an input to the Resolver Cookie.) This server 331 secret SHOULD have 64 bits of entropy [RFC4086bis] and be changed 332 periodically (see Section 6.3). The selection of the pseudo-random 333 function is a private matter to the server as only the server needs 334 to recognize its own DNS cookies. An example method is the FNV-64 335 [FNV] of the request IP address, the Resolver Cookie, and the server 336 secret. That is 338 Server Cookie = 339 FNV-64 ( Server Secret | Request IP Address | Resolver Cookie ) 341 where "|" represents concatenation. 343 A server MUST NOT use the same Server Cookie value for responses to 344 all resolvers. 346 4.3 Error Code 348 The Error Code field MUST have one of the values listed below. 350 Requests have a COOKIE OPT Error Code equal to one of the following 351 two values: 353 Zero, if the resolver believes the Server Cookie field is 354 correct, or 356 CKPING (Cookie PING), if the resolver does not know the correct 357 value for the Server Cookie field. 359 (In all cases, the RCODE in a DNS request header is zero.) 361 Replies have a COOKIE OPT with an Error Code equal to one of the 362 following five values: 364 Zero, if the request they respond to had one COOKIE OPT with a 365 correct Server Cookie. 367 NOCOOKIE, in which case the DNS reply header RCODE field is 368 Refused. 370 BADCOOKIE, in which case the DNS reply header RCODE field is 371 Refused. 373 MANYCOOKIE, in which case the DNS reply header RCODE field is 374 FormErr. 376 CKPINGR (Cookie PING Response), which case the DNS reply RCODE 377 field might be any value (see Section 5.2). 379 For more information on errors in replies see Section 6. 381 For further discussion of the Resolver Cookie field, see Section 5.1. 382 For further discussion of the Server Cookie field see Section 5.2. 384 5. DNS Cookies Protocol Description 386 The sections provide a general discussion of using DNS Cookies in the 387 DNS Protocol. More details are provided in Section 6. 389 5.1 Originating Requests 391 A DNS resolver that implements DNS cookies includes a DNS Cookie 392 option in every DNS request it sends unless DNS cookies are disabled 393 in that resolver. The DNS Cookie in a request includes a Resolver 394 Cookie as discussed in Section 4.1, a Server Cookie cached as soft 395 state associated with that server IP address from a previous DNS 396 response, and a zero Error Code field. 398 If the resolver has no cached Server Cookie for the server, then it 399 sets the Server Cookie field to any value and sets the Error Code 400 field to CKPING (Cookie Ping); this is the only case in which the 401 Error Code field in a COOKIE OPT in a request is non-zero. 403 5.2 Responding to Requests 405 The Server Cookie, when it occurs in a COOKIE OPT option in a 406 request, is intended to weakly assure the server that the request 407 came from a resolver at the source IP address used because the Server 408 Cookie value is the value that server would send to that resolver in 409 a response. 411 A DNS server that implements DNS cookies and for which DNS cookies 412 are not disabled always includes a DNS cookie in the response to a 413 DNS request that includes such a cookie. If the request did not 414 include a DNS cookie, inclusion of a DNS cookies in the response 415 depends on the server mode for that resolved (see Section 6.2). In 416 the DNS Cookie that the server includes, the Resolver Cookie field is 417 copied from that field in the request. If there was no cookie in the 418 request, it may be set to any value. The Server Cookie field is set 419 as discussed in Section 4.2 and the Error Code field is set as 420 specified in Section 6. 422 5.3 Processing Responses 424 The Resolver Cookie, when it occurs in a COOKIE OPT option in a DNS 425 reply, is intended to weakly assure the resolver that the reply came 426 from a server at the source IP address use in the response packet 427 because the Resolver Cookie value is the value that resolver would 428 send to that server in a request. 430 A DNS resolver that implements DNS cookies and for which DNS cookies 431 are not disabled examines response for DNS cookies and will discard 432 the response if it contains an incorrect Resolver Cookie or has 433 multiple cookies. If the COOKIE OPT option Resolver Cookie is correct 434 and the Error Code field is not NOCOOKIE, MANYCOOKIES, it caches the 435 Server Cookie provided even if the response is an error response. The 436 rest of the response is then processed normally. 438 6. DNS Cookie Policies and Implementation 440 Obviously, DNS resolvers that do not implement DNS cookies do not 441 include them in requests and ignore them in replies and DNS servers 442 that do not implement DNS cookies ignore them in requests and do not 443 include the in replies. 445 DNS resolvers and servers that implement DNS cookies will adopt one 446 of various policies regarding cookies. These policies SHOULD be 447 logically settable on a per server IP address basis in resolvers and 448 on a per resolver ( IP address, Resolver Cookie ) pair in servers. 449 Thus a resolver can have different policies for different servers, 450 based on the server IP address. And a server can have different 451 policies for different resolvers, based on the resolver IP address 452 and Resolver Cookie. Of course, the actual implementation of the 453 configuration of these policies may be for blocks or classes of 454 values or use sparse array techniques or the like. 456 The policy in each case is either "Disabled", "Enabled", or 457 "Enforced" as described below. 459 6.1 Resolver Policies and Implementation 461 A resolver will logically have one of the following three modes of 462 operation or "policies" for each DNS server as distinguished by 463 server IP Address. 465 Disabled: 466 Never include a COOKIE OPT option in requests. 467 Ignore COOKIE OPT options in replies. 469 Enabled: 470 Always include a COOKIE OPT option in requests. If a cached Server 471 Cookie for the server is not available, the Server Cookie field 472 can be set to any value and the COOKIE OPT Error Code field is 473 set to CKPING (Cookie Ping); otherwise, the Error Code field is 474 set to zero. 475 Normally process replies without a COOKIE OPT option. 476 Silently ignore replies with more than one COOKIE OPT option. 477 Silently ignore replies with one COOKIE OPT option if it has an 478 incorrect Resolver Cookie value. 479 On receipt of a reply with one COOKIE OPT option carrying the 480 correct Resolver Cookie value (even if it is a DNS error 481 response), the DNS client performs normal response processing, 482 including caching the received Server Cookie as soft state, and 483 it MUST change to the Enforced policy for DNS requests to that 484 DNS server IP address. This policy change to Enforced is 485 treated as soft state with the same retention strategy as the 486 Server Cookie value for that server. On discard of that state 487 information, the policy for that DNS server IP address reverts 488 to Enabled. 490 Enforced: 491 Always include a COOKIE OPT option in requests. 492 Silently ignore all replies that do not include exactly one COOKIE 493 OPT option having the correct Resolver Cookie value. 494 On receipt of a reply with one COOKIE OPT option carrying the 495 correct Resolver Cookie value (even if it is a DNS error 496 response), the DNS client performs normal response processing, 497 including caching the received Server Cookie. If a copy of the 498 same Server Cookie value is already cached for that server, 499 then its retention probability should be increased. For 500 example, if a time out is being used for the discard to cached 501 Server Cookies, that time out should be extended. 503 6.2 Server Policies and Implementation 505 A server will logically have one of the following three modes of 506 operation or "policies" for each DNS resolver as discussed below. 508 Disabled: 509 Ignore COOKIE OPT options in requests. 510 Never include a COOKIE OPT option in replies. 512 Enabled: 513 Include a COOKIE OPT option in replies to requests that include a 514 COOKIE OPT. 515 Normally process requests without a COOKIE OPT option except that 516 it is RECOMMENDED that the processing of burdensome requests 517 and requests producing replies substantially longer than the 518 request be significantly rate limited. 519 Ignore, other than sending a FormErr/MANYCOOKIE error reply, any 520 request with more than one COOKIE OPT option. Such replies MAY 521 be rate limited and SHOULD be as short as practical. 522 Ignore, other than sending a BADCOOKIE error reply, any request 523 with one COOKIE OPT option if it has an incorrect Server Cookie 524 unless the request COOKIE has an Error Code of CKPING (Cookie 525 Ping) in which case the response has an Error Code of CKPINGR 526 (Cookie Ping Response). Such replies MAY be rate limited and 527 SHOULD be as short as practical. 528 On receipt of a request with one COOKIE OPT option carrying the 529 correct Server Cookie value and an Error Code of zero, the DNS 530 server performs normal request processing and it SHOULD switch 531 to the Enforced policy for DNS requests from that resolver IP 532 address with that Resolver Cookie in the request. This policy 533 change to Enforced is treated as soft state. On discard of that 534 state information, the policy for that resolver IP and Resolver 535 Cookie pair reverts to Enabled. 537 Enforced: 538 Always include a COOKIE OPT option in replies. 539 Ignore requests without a COOKIE OPT option or with more than one 540 COOKIE OPT option, other than returning a NOCOOKIE or 541 MANYCOOKIE DNS error respectively. Such replies MAY be rate 542 limited to any particular IP address and SHOULD be as short as 543 practical. 544 Ignore requests with one COOKIE OPT option if they have an 545 incorrect Server Cookie, other than returning a BADCOOKIE error 546 message, unless the request has an Error Code of CKPING in 547 which case the response has an Error Code of CKPINGR. Such 548 replies MAY be rate limited and SHOULD be as short as 549 practical. 550 If a request has one COOKIE OPT option with a correct Server 551 Cookie and an Error Code of zero, perform normal processing of 552 the request. 554 6.3 Resolver and Server Secret Rollover 556 Resolvers and servers MUST NOT continue to use the same secret in new 557 queries and responses, respectively, for more than 14 days and SHOULD 558 NOT continue to do so for more than 1 day. It is RECOMMENDED that a 559 resolver keep the Resolver Cookie it is expecting in a reply 560 associated with the outstanding query to avoid rejection of replies 561 due to a bad Resolver Cookie right after a change in the Resolver 562 Secret. It is RECOMMENDED that a server retain its previous secret 563 for a period of time not less than 1 second or more than 3 minutes, 564 after a change in its secret, and consider queries with Server 565 Cookies based on its previous secret to have a correct Server Cookie 566 during that time. 568 Receiving a suddenly increased level of requests with bad Server 569 Cookies or replies with bad Resolver Cookies would be a good reason 570 to believe a server or resolver likely to be under attack and should 571 consider more frequent rollover of its secret. 573 6.4 Implementation Requirement 575 DNS resolvers and servers SHOULD implement DNS cookies. 577 DNS resolvers SHOULD operate in and be shipped so as to default to 578 the Enabled or Enforced mode for all servers. 580 DNS servers SHOULD operate in and be shipped so as to default to the 581 Enabled or Enforced mode for all resolvers they are willing to 582 service. 584 7. NAT Considerations and AnyCast Server Considerations 586 In the Classic Internet, DNS Cookies could simply be a pseudo-random 587 function of the resolver IP address and a sever secret or the server 588 IP address and a resolver secret. You would want to compute the 589 Server Cookie that way, so a resolver could cache its Server Cookie 590 for a particular server for an indefinitely amount of time and the 591 server could easily regenerate and check it. You could consider the 592 Resolver Cookie to be a weak resolver signature over the server IP 593 address that the resolver checks in replies and you could extend this 594 weak signature to cover the request ID, for example, or any other 595 information that is returned unchanged in the reply. 597 But we have this reality called NAT [RFC3022], Network Address 598 Translation (including, for the purposes of this document, NAT-PT, 599 Network Address and Protocol Translation, which has been declared 600 Historic [RFC4966]). There is no problem with DNS transactions 601 between resolvers and servers behind a NAT box using local IP 602 addresses. Nor is there a problem with NAT translation of internal 603 addresses to external addresses or translations between IPv4 and IPv6 604 addresses, as long as the address mapping is relatively stable. 605 Should the external IP address an internal resolver being mapped to 606 change occasionally, the disruption is little more than when a 607 resolver rolls-over its DNS COOKIE secret. And normally external 608 access to a DNS server behind a NAT box is handled by a fixed mapping 609 which forwards externally received DNS requests to a specific host. 611 However, NAT devices sometimes also map ports. This can cause 612 multiple DNS requests and responses from multiple internal hosts to 613 be mapped to a smaller number of external IP addresses, such as one 614 address. Thus there could be many resolvers behind a NAT box that 615 appear to come from the same source IP address to a server outside 616 that NAT box. If one of these were an attacker (think Zombie or 617 Botnet), that behind-NAT attacker could get the Server Cookie for 618 some server for the outgoing IP address by just making some random 619 request to that server. It could then include that Server Cookie in 620 the COOKIE OPT of requests to the server with the forged local IP 621 address of some other host and/or resolver behind the NAT box. 622 (Attacker possession of this Server Cookie will not help in forging 623 responses to cause cache poisoning as such responses are protected by 624 the required Resolver Cookie.) 626 To fix this potential defect, it is necessary to distinguish 627 different resolvers behind a NAT box from the point of view of the 628 server. It is for this reason that the Server Cookie is specified as 629 a pseudo-random function of both the request source IP address and 630 the Resolver Cookie. From this inclusion of the Resolver Cookie in 631 the calculation of the Server Cookie, it follows that a stable 632 Resolver Cookie, for any particular server, is needed. If, for 633 example, the request ID was included in the calculation of the 634 Resolver Cookie, it would normally change with each request to a 635 particular server. This would mean that each request would have to 636 be sent twice: first to learn the new Server Cookie based on this new 637 Resolver Cookie based on the new ID and then again using this new 638 Resolver Cookie to actually get an answer. Thus the input to the 639 Resolver Cookie computation must be limited to the server IP address 640 and one or more things that change slowly such as the resolver 641 secret. 643 In principle, there could be a similar problem for servers, not due 644 to NAT but due to mechanisms like anycast which may cause queries to 645 a DNS server at an IP address to be delivered to any one of several 646 machines. (External queries to a DNS server behind a NAT box usually 647 occur via port forwarding such that all such queries go to one host.) 648 However, it is impossible to solve this the way the similar problem 649 was solved for NATed resolvers; if the Server Cookie was included in 650 the calculation of the Resolver Cookie the same way the Resolver 651 Cookie is included in the Server Cookie, you would just get an almost 652 infinite series of errors as a request was repeatedly retried. 654 For servers accessed via anycast to successfully support DNS COOKIES, 655 the server clones must either all use the same server secret or the 656 mechanism that distributes queries to them must cause the queries 657 from a particular resolver to go to a particular server for a 658 sufficiently long period of time that extra queries due to changes in 659 Server Cookie resulting from accessing different server machines are 660 not unduly burdensome. (When such anycast accessed servers act as 661 recursive servers or otherwise act as resolvers they normally use a 662 different unique address to source their queries to avoid confusion 663 in the delivery of responses.) 665 For simplicity, it is RECOMMENDED that the same server secret be used 666 by each DNS server in a set of anycast servers. If there is limited 667 time skew in updating this secret in different anycast servers, this 668 can be handled by a server accepting requests containing a Server 669 Cookie based on either its old or new secret for the maximum likely 670 time period of such time skew (see also Section 6.3). 672 8. Deployment 674 The DNS cookies mechanism is designed for incremental deployment and 675 to complement the orthogonal techniques in [RFC5452]. Either or both 676 techniques can be deployed independently at each DNS server and 677 resolver. 679 In particular, a DNS server or resolver that implements the DNS 680 COOKIE mechanism and is in the Enabled mode will interoperate 681 successfully with a DNS resolver or server that does not implement 682 this mechanism although, of course, in this case it will not get the 683 benefit of the mechanism. When such a server or resolver 684 interoperates with a resolver or server which also implements the DNS 685 cookies mechanism and is in Enabled or Enforced mode, this is 686 recognized and, for that transaction partner, it latches up into the 687 Enforced mode and gets the full benefit of the DNS cookies mechanism 688 until this soft state lapses and it reverts to Enabled mode. 690 9. IANA Considerations 692 IANA will assign the following code points: 694 The OPT option value for COOKIE is . 696 Three new DNS error codes are assigned values in the range above 697 15 and below 3841 as listed below: 699 NOCOOKIE is assigned the value TBD (23 suggested). 700 BADCOOKIE is assigned the value TBD (24 suggested). 701 MANYCOOKIE is assigned the value TBD (25 suggested). 703 Two new DNS error codes are assigned in the range above 4095 and 704 below 65535: 706 CKPING (Cookie PING) is assigned the value TBD (4096 707 suggested). 709 CKPINGR (Cookie PING Response) is assigned the value RBD (4097 710 suggested). 712 10. Security Considerations 714 DNS Cookies provide a weak form of authentication of DNS requests and 715 responses. In particular, they provide no protection at all against 716 "on-path" adversaries; that is, they provide no protection against 717 any adversary that can observe the plain text DNS traffic, such as an 718 on-path router, bridge, or any device on an on-path shared link 719 (unless the DNS traffic in question on that path is encrypted). 721 For example, if a host is connected via an unsecured IEEE 802.11 link 722 (Wi-Fi), any device in the vicinity that could receive and decode the 723 802.11 transmissions must be considered "on-path". On the other hand, 724 in a similar situation but one where 802.11 Robust Security (WPAv2) 725 is appropriately deployed on the Wi-Fi network nodes, only the Access 726 Point via which the host is connecting is "on-path". 728 Despite these limitations, use of DNS Cookies on the global Internet 729 is expected to provide a substantial reduction in the available 730 launch points for the traffic amplification and denial of service 731 forgery attacks described in Section 2 above. 733 Should stronger message/transaction security be desired, it is 734 suggested that TSIG or SIG(0) security be used (see Section 3.2); 735 however, it may be useful to use DNS Cookies in conjunction with 736 these features. In particular, DNS Cookies could screen out many DNS 737 messages before the cryptographic computations of TSIG or SIG(0) are 738 required and, if SIG(0) is in use, DNS Cookies could usefully screen 739 out many requests given that SIG(0) does not screen requests but only 740 authenticates the response of complete transactions. 742 10.1 Cookie Algorithm Considerations 744 The cookie computation algorithm for use in DNS Cookies SHOULD be 745 FNV-64 [FNV] or some stronger algorithm because an excessively weak 746 or trivial algorithm could enable adversaries to guess cookies. 747 However, in light of the weak plain-text token security provided by 748 DNS Cookies, a strong cryptography hash algorithm is probably not 749 warranted in many cases, and would cause an increased computational 750 burden. Nevertheless there is nothing wrong with using something 751 stronger, for example, HMAC-SHA256-64 [RFC6234], assuming a DNS 752 processor has adequate computational resources available. DNS 753 processors that feel the need for somewhat stronger security without 754 a significant increase in computational load should consider more 755 frequent changes in their resolver and/or server secret; however, 756 this does require more frequent generation of a cryptographically 757 strong random number [RFC4086bis]. 759 Acknowledgements 761 The contributions of the following are gratefully acknowledged: 763 Tim Wicinski 765 Normative References 767 [FNV] - G. Fowler, L. C. Noll, K.-P. Vo, D. Eastlake, "The FNV Non- 768 Cryptographic Hash Algorithm", draft-eastlake-fnv, work in 769 progress. 771 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, March 1997. 774 [RFC6891] - Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 775 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 777 [RFC4086bis] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, 778 "Randomness Requirements for Security", draft-eastlake- 779 randomness3, work in progress. 781 Informative References 783 [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 784 Wellington, "Secret Key Transaction Authentication for DNS 785 (TSIG)", RFC 2845, May 2000. 787 [RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 788 RR)", RFC 2930, September 2000. 790 [RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures 791 ( SIG(0)s )", RFC 2931, September 2000. 793 [RFC3022] - Srisuresh, P. and K. Egevang, "Traditional IP Network 794 Address Translator (Traditional NAT)", RFC 3022, January 2001. 796 [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 797 Rose, "DNS Security Introduction and Requirements", RFC 4033, 798 March 2005. 800 [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 801 Rose, "Resource Records for the DNS Security Extensions", RFC 802 4034, March 2005. 804 [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 805 Rose, "Protocol Modifications for the DNS Security Extensions", 806 RFC 4035, March 2005. 808 [RFC4966] - Aoun, C. and E. Davies, "Reasons to Move the Network 809 Address Translator - Protocol Translator (NAT-PT) to Historic 810 Status", RFC 4966, July 2007. 812 [RFC5452] - Hubert, A. and R. van Mook, "Measures for Making DNS More 813 Resilient against Forged Answers", RFC 5452, January 2009. 815 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 816 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 817 2011. 819 Author's Address 821 Donald E. Eastlake 3rd 822 Huawei Technologies 823 155 Beaver Street 824 Milford, MA 01757 USA 826 Telephone: +1-508-333-2270 827 EMail: d3e3e3@gmail.com 829 Copyright, Disclaimer, and Additional IPR Provisions 831 Copyright (c) 2014 IETF Trust and the persons identified as the 832 document authors. All rights reserved. 834 This document is subject to BCP 78 and the IETF Trust's Legal 835 Provisions Relating to IETF Documents 836 (http://trustee.ietf.org/license-info) in effect on the date of 837 publication of this document. Please review these documents 838 carefully, as they describe your rights and restrictions with respect 839 to this document. Code Components extracted from this document must 840 include Simplified BSD License text as described in Section 4.e of 841 the Trust Legal Provisions and are provided without warranty as 842 described in the Simplified BSD License.