idnits 2.17.00 (12 Aug 2021) /tmp/idnits29297/draft-eastlake-dnsext-cookies-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 645. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 2006) is 5818 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: 'RFC 4033' is mentioned on line 600, but not defined == Missing Reference: 'RFC 4035' is mentioned on line 608, but not defined == Missing Reference: 'RFC 4034' is mentioned on line 604, but not defined == Missing Reference: 'RFC 2845' is mentioned on line 587, but not defined ** Obsolete undefined reference: RFC 2845 (Obsoleted by RFC 8945) == Missing Reference: 'RFC 2931' is mentioned on line 594, but not defined == Missing Reference: 'RFC 2930' is mentioned on line 591, but not defined == Missing Reference: 'RFC 3022' is mentioned on line 597, but not defined == Missing Reference: 'RFC 2766' is mentioned on line 428, but not defined ** Obsolete undefined reference: RFC 2766 (Obsoleted by RFC 4966) == Unused Reference: 'RFC 2119' is defined on line 569, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Motorola Laboratories 3 Expires: December 2006 June 2006 5 Domain Name System (DNS) Cookies 6 ------ ---- ------ ----- ------- 7 9 Status of This Document 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This draft is intended to be become a Proposed Standard RFC. 17 Distribution of this document is unlimited. Comments should be sent 18 to the author or the DNSEXT working group mailing list 19 . 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 38 DNS cookies are a light-weight DNS transaction security mechanism. 39 They provides limited protection to DNS servers and resolvers against 40 a variety of increasingly common denial-of-service and cache 41 poisoning attacks by off-path attackers. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Table of Contents 49 Status of This Document....................................1 50 Abstract...................................................1 51 Copyright Notice...........................................1 53 Table of Contents..........................................2 55 1. Introduction............................................3 56 1.1 Contents of This Document..............................3 57 1.2 Definitions............................................3 58 2. Threats Considered......................................4 59 2.1 Denial-of-Service Attacks..............................4 60 2.1.1 DNS Server Denial-of-Service.........................4 61 2.1.2 Selected Host Denial-of-Service......................5 62 2.2 Cache Poisoning Attacks................................5 63 3. Comments on Existing DNS Security.......................5 64 4. The COOKIE RR...........................................6 65 4.1 Resolver Cookies.......................................7 66 4.2 Server Cookies.........................................7 67 5. General Policies and Implementation.....................8 68 5.1 Resolver Policies and Implementation...................8 69 5.2 Server Policies and Implementation.....................9 70 5.3 Implementation Requirements...........................10 71 6. NAT and AnyCast Considerations.........................10 72 7. IANA Considerations....................................12 73 8. Security Considerations................................12 74 9. Copyright and Disclaimer...............................13 75 10. Normative References..................................13 76 11. Informative References................................13 78 Author's Address..........................................15 79 Additional IPR Provisions.................................15 80 Expiration and File Name..................................15 82 1. Introduction 84 The Domain Name System (DNS) provides a replicated distributed 85 database which stores "resource records" (RRs) under hierarchical 86 domain names. DNS data is structured into CLASSes and zones which 87 can be independently maintained. See [STD 13], [RFC 2181] 88 familiarity with which is assumed. 90 As with many core Internet protocols, DNS was designed at a time when 91 the Internet had only a small pool of trusted users. As the Internet 92 has exploded to a global information utility the DNS has increasingly 93 been subject to abuse and been used as a vector for abuse. 95 This document describes DNS cookies, a light-weight DNS transaction 96 security mechanism. They provides limited protection to DNS servers 97 and resolvers against a variety of increasingly common denial-of- 98 service and cache poisoning attacks by off-path attackers. 100 1.1 Contents of This Document 102 In Section 2, we discuss the threats against which DNS cookies 103 provides some protection. 105 Section 3 describes existing DNS security mechanisms and why they are 106 not adequate subsitutes for DNS cookies. 108 Section 4 describes the COOKIE RR including how recommendations for 109 calculating Resolver and Server Cookies. 111 Section 5 describes the processing of COOKIE RRs by resolvers and 112 server and policies for such processing. 114 Section 6 discusses some NAT and anycast related DNS Cookies design 115 considerations. 117 Sections 7 and 8 describe IANA and Security Considerations. 119 1.2 Definitions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119. 125 An "off-path attacker", for a particular DNS resolver and server, is 126 defined as an attacker which cannot observe the legitimate plain text 127 DNS requests and responses between that resolver and server. 129 "Soft state" indicates information learned or derived by a host which 130 may be discarded when indicated by the policies of that host. For 131 example, it could be discarded after a period of time or when storage 132 for caching such data becomes full. If operations requiring that soft 133 state continue after it has been discarded, it will be automatically 134 re-generated, albeit at some cost. 136 "Silently discarded" indicates that there are no DNS protocol message 137 consequences; however, it is RECOMMENDED that appropriate debugging 138 network management facilities be included in implementations, such as 139 a counter of the occurrences of each type of such events. 141 The term "IP address" is used herein in a length independent manner 142 and refers interchangeably to IPv4 and IPv6 addresses. 144 2. Threats Considered 146 DNS cookies are intended to provide significant but limited 147 protection against certain denial-of-service and cache poisoning 148 attacks by off-path attackers described below. 150 2.1 Denial-of-Service Attacks 152 The normal form of the denial-of-service attacks considered herein is 153 to send DNS requests to the attacked server with forged source IP 154 addresses. The intent can be to attack the server or a selected host 155 as described below. 157 2.1.1 DNS Server Denial-of-Service 159 DNS requests that are accepted cause work on the part of DNS servers. 160 This is particularly true for recursive servers which may issue one 161 or more requests and process the responses thereto in order to 162 determine their response to the initial query. And the situation is 163 even worse for recursive servers implementing DNSSEC [RFC 4033], [RFC 164 4034], [RFC 4035] because they may be induced to perform burdensome 165 public key cryptographic computations in attempts to verify the 166 authenticity of data they retrieve in trying to answer the request. 168 While the burden cause by such requests is not dependent on a forged 169 IP source address, the use of such addresses makes 170 + the source of the requests causing the denial-of-service requests 171 to be harder to find and 172 + administrative restriction of the IP addresses from which such 173 requests should be honored harder to enforce. 175 2.1.2 Selected Host Denial-of-Service 177 Request with a forged IP address causes a response to be sent to that 178 forged IP address. Thus the forging of many such requests can, 179 indirectly, result in enough traffic being sent to the forged IP 180 address to interfere with service to the host at the IP address. 181 Furthermore, it is generally easy in the DNS to create short requests 182 that produce much longer responses. Thus a DNS server can be used as 183 not only a way to obscure the true source of an attack but as a 184 traffic amplifier to make the attack more effective. 186 Use of DNS cookies severely limits the traffic amplification that can 187 be obtained by attackers off path for the server and the attacked 188 host. Enforced DNS cookies would make it hard for an off path 189 attacker to cause any more than a brief error response to be send to 190 a forged IP address. Furthermore, DNS cookies make it more effective 191 to implement a rate limiting scheme for bad DNS cookie error response 192 from the server which would further restrict selected host denial-of- 193 service traffic from that server. 195 2.2 Cache Poisoning Attacks 197 The form of the cache poisoning attacks considered is to send forged 198 replies to a resolver. Modern network speeds for well connected hosts 199 are such that, by forging replies from the IP addresses of heavily 200 used DNS servers and for popular names to a heavily used resolver, 201 there can be an unacceptably high probability of randomly coming up 202 with a reply that will be accepted and cause false DNS information to 203 be cached by that resolver. This can be used to facilitate phishing 204 attacks and other diversion of legitimate traffic to a compromised or 205 malicious host such as a web server. 207 3. Comments on Existing DNS Security 209 Two forms of security have been added to DNS: 211 The first, called DNSSEC and described in [RFC 4033], [RFC 4034], 212 [RFC 4035], provides data origin authentication and authenticated 213 denial of existence. It is being deployed very slowly and, in any 214 case, can make some denial-of-service attacks worse because of the 215 high cryptographic computational load it can require and the 216 increased size in DNS packets that it can produces. 218 The second form of security which has been added to DNS provides 219 "transaction" security through TSIG [RFC 2845] or SIG(0) [RFC 2931]. 220 TSIG could provide near perfect protection against the attacks for 221 which DNS cookies provide weak and incomplete protection; however, 222 TSIG is hard to deploy in the general Internet because of the burden 223 it imposes of pre-agreement and key distribution between pairs of 224 resolvers and servers and because it requires time synchronization 225 between resolver and server. 227 TKEY [RFC 2930] can solve the problem of key distribution for TSIG 228 but some modes of TKEY impose substantial cryptographic computations 229 loads and can be dependent on the deployment of DNSSEC. 231 SIG(0) provides less protection than TSIG or, in one way, even DNS 232 cookies, because it does not authentication requests, only complete 233 transactions. In any case, it also depends on the deployment of 234 DNSSEC and requires computationally burdensome public key 235 cryptographic operations. 237 Thus, none of the previous forms of DNS security are a suitable 238 substitute for DNS cookies, which provide light weight transaction 239 authentication of DNS requests and responses with no requirement for 240 pre-configuration. 242 4. The COOKIE RR 244 COOKIE is a meta-RR that can be included once in the Additional 245 Information portion of DNS requests and responses. 247 The RDATA portion of the COOKIE RR is 18 bytes long as shown below. 249 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Resolver Cookie upper half | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Resolver Cookie lower half | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Server Cookie upper half | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Server Cookie lower half | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Error Code | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 The Resolver and Server Cookies are stored in network byte order and 264 are determined as described below. 266 The Error Code field MUST BE zero in requests and in responses unless 267 the response is communicating a DNS cookie related error. Three 268 values are possible for Error Code: NOCOOKIE and BADCOOKIE which 269 occur with a Refused RCODE in the DNS response header, and MANYCOOKIE 270 which occurs with a FormErr RCODE in the DNS header. More information 271 on the generation of error response appears in Section 5 below. 273 4.1 Resolver Cookies 275 The Resolver Cookie, when it occurs in a COOKIE RR in a DNS response, 276 is intended to weakly assure the resolver that the response came from 277 a server at the indicated source IP address. 279 Servers remember the Resolver Cookie that appears in a query long 280 enough to use it in the construction of the COOKIE RR in the 281 corresponding response if such a COOKIE RR is included in that 282 response. 284 The Resolver Cookie SHOULD be a pseudo-random function of the server 285 IP address and a secret quantity known only to the resolver. This 286 resolver secret SHOULD have 64 bits of entropy [RFC 4086] and MAY be 287 changed periodically. The RECOMMENDED method is the HMAC-MD5-64 [RFC 288 1321], [RFC 2104] of the server IP address and the resolver secret. 289 That is 291 Resolver Cookie = 292 Truncate-64 ( HMAC-MD5 ( Server IP, Resolver Secret ) ) 294 A resolver MUST NOT use the same Resolver Cookie value for queries to 295 all servers. 297 4.2 Server Cookies 299 The Server Cookie, when it occurs in a COOKIE RR in a query, is 300 intended to weakly assure the server that the query legitimately came 301 from a resolver at the indicated source IP address that is using the 302 indicated Resolver Cooker. 304 Resolvers learn Server Cookies and retain them as soft state 305 associated with the server IP address. They learn them from the 306 Server Cookie that appears in the COOKIE RR of a reply that also has 307 the correct Resolver Cookie, even if that reply is an error message. 309 The Server Cookie SHOULD be a pseudo-random function of the request 310 source IP address, the request Resolver Cookie, and a secret quantity 311 known only to the server. This server secret SHOULD have 64 bits of 312 entropy [RFC 4086] and SHOULD be changed periodically such as daily. 313 The RECOMMENDED method is the HMAC-MD5-64 [RFC 1321], [RFC 2104] of 314 the request IP address, the Resolver Cookie, and the server secret. 315 That is 317 Server Cookie = Truncate-64 ( 318 HMAC-MD5 ( (Request IP | Resolver Cookie), Server Secret ) ) 320 where "|" represents concatenation. A server MUST NOT use the same 321 Server Cookie value for responses to all requests. 323 5. General Policies and Implementation 325 DNS resolvers and servers will adopt one of three policies regarding 326 cookies. These policies SHOULD be logically settable on a per server 327 IP address basis for resolvers and a per resolver IP address, 328 Resolver Cookie pair for servers. Thus a resolver can have different 329 policies for different servers, based on the server IP address. And a 330 server can have different policies for different resolvers, based on 331 the resolver IP address and Resolver Cookie. Of course, the actual 332 implementation of setting these policies may by for blocks of values 333 or use sparse array techniques. 335 The policy for each value is either "Disabled", "Enabled", or 336 "Enforced" as described below. 338 5.1 Resolver Policies and Implementation 340 Disabled: 341 Never include a COOKIE RR in requests. 342 Ignore COOKIE RRs in the Additional Information section of 343 responses. 345 Enabled: 346 Always include a COOKIE RR in the Additional Information section 347 of requests. If a cached Server Cookie for the server is not 348 available, the Server Cookie field can be set to any value. 349 Normally process responses without a COOKIE RR. 350 Silently ignore responses with more than one COOKIE RR. 351 Silently ignore responses with one COOKIE RR if that RR has an 352 incorrect Resolver Cookie value. 353 On receipt of a response with one COOKIE RR and that RR having the 354 correct Resolver Cookie value (even if it is a BADCOOKIE error 355 response), perform normal response processing, including 356 caching the received Server Cookie and MUST change to the 357 Enforced policy for DNS requests to that server IP address. 359 This policy change SHOULD be treated as soft state with the 360 same discard policy as the Server Cookie value for that server. 361 On discarding that state information, the policy for that 362 server reverts to Enabled. 364 Enforced: 365 Always include a COOKIE RR in the Additional Information section 366 of requests. 367 Silently ignore all responses that do not include exactly one 368 COOKIE RR with that RR having the correct Resolver Cookie 369 value. Normally process responses which do include such a 370 COOKIE RR. 372 5.2 Server Policies and Implementation 374 Disabled: 375 Ignore COOKIE RRs in requests. 376 Never include a COOKIE RR in responses. 378 Enabled: 379 Normally process requests without a COOKIE RR. 380 Ignore, other than sending a MANYCOOKIE error response, any 381 request with more than one COOKIE RR. 382 Ignore, other than sending a BADCOOKIE error response, any query 383 with one COOKIE RR if that RR has an incorrect Server Cookie. 384 On receipt of a request with a COOKIE RR having the correct Server 385 Cookie value, perform normal request processing and SHOULD 386 adopt the Enforced policy for DNS requests from that resolver 387 IP address with the Resolver Cookie in the request. This policy 388 change for that resolver SHOULD be treated as soft state. On 389 discarding that state information, the policy for that resolver 390 IP and Resolver Cookie pair reverts to enabled. 391 Always include a COOKIE RR in responses. 393 Enforced: 394 Ignore requests without a COOKIE RR or with more than one COOKIE 395 RR, other than sending a NOCOOKIE or MANYCOOKIE error message 396 respectively. 397 Ignore requests with one COOKIE RR if that RR has an incorrect 398 Server Cookie, other than sending a BADCOOKIE error message. 399 If a request has one COOKIE RR with a correct Server Cookie, 400 perform normal processing of the request. 401 Include a COOKIE RR in all responses. 403 5.3 Implementation Requirements 405 DNS resolvers and servers MUST implement DNS cookies. 407 DNS resolvers SHOULD operate in and be shipped so as to default to 408 the Enabled or Enforced mode for all servers. 410 DNS servers SHOULD operate in and be shipped so as to default to the 411 Enabled or Enforced mode for all resolvers they are willing to 412 service. 414 6. NAT and AnyCast Considerations 416 In the Classic Internet, DNS Cookies could simply be a pseudo-random 417 function of the resolver IP address and a sever secret or the server 418 IP address and a resolver secret. You would want to compute the 419 Server Cookie that way, so a resolver could cache its Server Cookie 420 for a particular server for an indefinitely amount of time and the 421 server could easily regenerate and check it. You could consider the 422 Resolver Cookie to be a resolver signature over the server IP address 423 which the resolver checks in responses and you could extend this 424 signature to cover the ID for example. 426 But we have this wart called NAT [RFC 3022], Network Address 427 Translation (including therein for the purposes of this document NAT- 428 PT [RFC 2766], Network Address and Protocol Translation). There is no 429 problem with DNS transactions between resolvers and servers behind a 430 NAT box using local IP addresses. Nor is there a problem with NAT 431 translation of internal addresses to external addresses or 432 translations between IPv4 and IPv6 addresses, as long as the address 433 mapping is relatively stable. Should an internal resolver being 434 mapped to a particular external IP address change occasionally, the 435 disruption is no more than when a resolver rolls-over its DNS COOKIE 436 secret. And normally external access to a DNS server behind a NAT box 437 is handled by a fixed mapping which forwards externally received DNS 438 requests to a specific host. 440 However, NAT devices sometimes also map ports. This can cause 441 multiple DNS requests and responses from multiple internal hosts to 442 be simultaneously mapped to a smaller number of external IP 443 addresses, frequently one. There could be many resolvers behind a 444 NAT box that appear to come from the same source IP address to a 445 server outside that NAT box.. If one of these were an attacker 446 (think Zombie or Botnet), that behind-NAT attacked could get the 447 Server Cookie for some server for the outgoing IP address by just 448 making some random request to that server. It could then include that 449 Server Cookie in the COOKIE RR of requests to the server with the 450 forged IP address of the local IP address of some other host and/or 451 resolver behind the NAT box. (Attacker possession of this Server 452 Cookie will not help in forging responses to cause cache poisoning as 453 such responses are protected by the required Resolver Cookie.) 455 To fix this potential defect, it is necessary to distinguish 456 different resolvers behind a NAT box from the point of view of the 457 server. It is for this reason that the Server Cookie is specified as 458 a pseudo-random function of both the request source IP address and 459 the Resolver Cookie. From this inclusion of the Resolver Cookie in 460 the calculation of the Server Cookie, it follows that a stable 461 Resolver Cookie, for any particular server, is needed. If, for 462 example, the request ID was included in the calculation of the 463 Resolver Cookie, it would normally change with each query to a 464 particular server. This would mean that each query would have to be 465 sent twice: first to learn the new Server Cookie based on this new 466 Resolver Cookie based on the new ID and then again using this new 467 Resolver Cookie to actually get an answer. Thus the input to the 468 Resolver Cookie computation must be limited to the server IP address 469 and one or more things that change slowly such as the resolver 470 secret. 472 In principle, there could be a similar problem for servers, not 473 particularly due to NAT but due to mechanisms like anycast which may 474 cause queries to a DNS server at an IP address to be delivered to any 475 one of several machines. (External queries to a DNS server behind a 476 NAT box usually occur via port forwarding such that all such queries 477 go to one host.) However, it is impossible to solve this the way the 478 similar problem was solved for NATed resolvers; if the Server Cookie 479 was included in the calculation of the Resolver Cookie the same way 480 the Resolver Cookie is included in the Server Cookie, you would just 481 get an almost infinite series of BADCOOKIE errors as a query was 482 repeatedly retried. 484 For server accessed via anycast or similar mechanisms to successfully 485 support DNS COOKIES, the server clones must either all use the same 486 server secret or the mechanism that distributes queries to them must 487 cause the queries from a particular resolver to go to a particular 488 server for a sufficiently long period of time that extra queries due 489 to changes in Server Cookie resulting from accessing different server 490 machines are not unduly burdensome. Such anycast accessed servers are 491 unlikely to be recursive servers or otherwise act as resolvers due to 492 the confusion that would result in getting responses to their queries 493 back to the right machine. If they are they must all use the same 494 resolver secret. 496 7. IANA Considerations 498 The meta-RRTYPE value for COOKIE is (TBD, 248 (0xF8) suggested). 500 Three new RCODES are assigned values above 15: 501 NOCOOKIE is assigned the value (TBD, 23 suggested). 502 BADCOOKIE is assigned the value (TBD, 24 suggested). 503 MANYCOOKIE is assigned the value (TBD, 25 suggested). 505 8. Security Considerations 507 DNS Cookies provide a weak form of authentication of DNS requests and 508 responses. In particular, they provide no protection at all against 509 "on-path" adversaries; that is, they provide no protection against 510 any adversary which can observe the plain text DNS traffic, such as 511 an on-path router, bridge, or any device on an on-path shared link 512 unless the DNS traffic in question on that link is appropriately 513 encrypted. 515 For example, if a host is connected via an unsecured IEEE 802.11 link 516 (Wi-Fi), any device in the vicinity that could receive and decode the 517 802.11 transmissions must be considered "on-path". On the other hand, 518 in a similar situation but one where 802.11i security is 519 appropriately deployed, of the Wi-Fi network nodes, only the Access 520 Point via which the host is connecting is "on-path". 522 Despite these limitations, use of DNS Cookies on the global Internet 523 are expected to provide a significant reduction in the available 524 launch points for the traffic amplification and denial of service 525 attacks described in Section 2 above. 527 The recommended cryptographic algorithm for use in DNS Cookies is 528 HMAC-MD5-64, that is, the HMAC scheme [RFC 2104] using the MD5 hash 529 function [RFC 1321] with its output truncated to 64-bits. Although 530 MD5 is now considered to be susceptible to collisions attacks, this 531 does not effect the security of HMAC-MD5. 533 In light of the weak plain-text token security provided by DNS 534 Cookies, stronger cryptography is probably not warranted. However, 535 there is nothing wrong with using, for example, HMAC-SHA256-64 536 instead, assuming a DNS processor has adequate computational 537 resources available. DNS processors that feel the need for somewhat 538 stronger security without a significant increase in computational 539 load should consider more frequent changes in their resolver and/or 540 server secret; however, this does require more frequent generation of 541 a cryptographically strong random number [RFC 4086] and a change in a 542 server secret will result in a number of BADCOOKIE rejected requests 543 from resolvers caching their old Server Cookie. 545 9. Copyright and Disclaimer 547 Copyright (C) The Internet Society (2006). 549 This document is subject to the rights, licenses and restrictions 550 contained in BCP 78, and except as set forth therein, the authors 551 retain all their rights. 553 This document and the information contained herein are provided on an 554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 556 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 557 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 558 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 561 10. Normative References 563 [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm", RFC 564 1321, April 1992. 566 [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 567 Hashing for Message Authentication", RFC 2104, February 1997. 569 [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS 573 Specification", RFC 2181, July 1997. 575 [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, 576 "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 578 [STD 13] 579 Mockapetris, P., "Domain names - concepts and facilities", STD 580 13, RFC 1034, November 1987. 582 Mockapetris, P., "Domain names - implementation and 583 specification", STD 13, RFC 1035, November 1987. 585 11. Informative References. 587 [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 588 Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", 589 RFC 2845, May 2000. 591 [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS 592 (TKEY RR)", RFC 2930, September 2000. 594 [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction 595 Signatures ( SIG(0)s )", RFC 2931, September 2000. 597 [RFC 3022] - Srisuresh, P. and K. Egevang, "Traditional IP Network 598 Address Translator (Traditional NAT)", RFC 3022, January 2001. 600 [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 601 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 602 2005. 604 [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 605 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 606 March 2005. 608 [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 609 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 610 4035, March 2005. 612 Author's Address 614 Donald E. Eastlake 3rd 615 Motorola Laboratories 616 155 Beaver Street 617 Milford, MA 01757 USA 619 Telephone: +1-508-786-7554 (w) 621 EMail: Donald.Eastlake@motorola.com 623 Additional IPR Provisions 625 The IETF takes no position regarding the validity or scope of any 626 Intellectual Property Rights or other rights that might be claimed 627 to pertain to the implementation or use of the technology 628 described in this document or the extent to which any license 629 under such rights might or might not be available; nor does it 630 represent that it has made any independent effort to identify any 631 such rights. Information on the procedures with respect to 632 rights in RFC documents can be found in BCP 78 and BCP 79. 634 Copies of IPR disclosures made to the IETF Secretariat and any 635 assurances of licenses to be made available, or the result of an 636 attempt made to obtain a general license or permission for the use 637 of such proprietary rights by implementers or users of this 638 specification can be obtained from the IETF on-line IPR repository 639 at http://www.ietf.org/ipr. 641 The IETF invites any interested party to bring to its attention 642 any copyrights, patents or patent applications, or other 643 proprietary rights that may cover technology that may be required 644 to implement this standard. Please address the information to the 645 IETF at ietf-ipr@ietf.org. 647 Expiration and File Name 649 This draft expires in December 2006. 651 Its file name is draft-eastlake-dnsext-cookies-00.txt