idnits 2.17.1 draft-eastlake-dnsext-cookies-01.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 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 660. ** 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 (October 2006) is 6397 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: 'RFC4033' is mentioned on line 615, but not defined == Missing Reference: 'RFC4034' is mentioned on line 619, but not defined == Missing Reference: 'RFC4035' is mentioned on line 623, but not defined == Missing Reference: 'RFC2845' is mentioned on line 602, but not defined ** Obsolete undefined reference: RFC 2845 (Obsoleted by RFC 8945) == Missing Reference: 'RFC2931' is mentioned on line 609, but not defined == Missing Reference: 'RFC2930' is mentioned on line 606, but not defined == Missing Reference: 'RFC3022' is mentioned on line 612, but not defined == Missing Reference: 'RFC2766' is mentioned on line 599, but not defined ** Obsolete undefined reference: RFC 2766 (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 8 errors (**), 0 flaws (~~), 10 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: April 2007 October 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 OPT option...................................6 65 4.1 Resolver Cookies.......................................7 66 4.2 Server Cookies.........................................8 67 5. General Policies and Implementation.....................8 68 5.1 Resolver Policies and Implementation...................9 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................................14 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 [STD13], [RFC2181] familiarity 88 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 specified as an OPT [RFC2671] option. They 97 provides limited protection to DNS servers and resolvers against a 98 variety of increasingly common denial-of-service and cache poisoning 99 attacks by off-path attackers. 101 1.1 Contents of This Document 103 In Section 2, we discuss the threats against which DNS cookies 104 provides some protection. 106 Section 3 describes existing DNS security mechanisms and why they are 107 not adequate substitutes for DNS cookies. 109 Section 4 describes the COOKIE OPT option including recommendations 110 for calculating Resolver and Server Cookies. 112 Section 5 describes the processing of COOKIE OPT optionby resolvers 113 and server and policies for such processing. 115 Section 6 discusses some NAT and anycast related DNS Cookies design 116 considerations. 118 Sections 7 and 8 describe IANA and Security Considerations. 120 1.2 Definitions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 An "off-path attacker", for a particular DNS resolver and server, is 127 defined as an attacker which cannot observe the legitimate plain text 128 DNS requests and responses between that resolver and server. 130 "Soft state" indicates information learned or derived by a host which 131 may be discarded when indicated by the policies of that host. For 132 example, it could be discarded after a period of time or when storage 133 for caching such data becomes full. If operations requiring that soft 134 state continue after it has been discarded, it will be automatically 135 re-generated, albeit at some cost. 137 "Silently discarded" indicates that there are no DNS protocol message 138 consequences; however, it is RECOMMENDED that appropriate debugging 139 network management facilities be included in implementations, such as 140 a counter of the occurrences of each type of such events. 142 The term "IP address" is used herein in a length independent manner 143 and refers interchangeably to IPv4 and IPv6 addresses. 145 2. Threats Considered 147 DNS cookies are intended to provide significant but limited 148 protection against certain denial-of-service and cache poisoning 149 attacks by off-path attackers described below. 151 2.1 Denial-of-Service Attacks 153 The normal form of the denial-of-service attacks considered herein is 154 to send DNS requests with forged source IP addresses to a server. The 155 intent can be to attack that server or a selected host as described 156 below. 158 2.1.1 DNS Server Denial-of-Service 160 DNS requests that are accepted cause work on the part of DNS servers. 161 This is particularly true for recursive servers which may issue one 162 or more requests and process the responses thereto in order to 163 determine their response to the initial query. And the situation is 164 even worse for recursive servers implementing DNSSEC [RFC4033], 165 [RFC4034], [RFC4035] because they may be induced to perform 166 burdensome public key cryptographic computations in attempts to 167 verify the authenticity of data they retrieve in trying to answer the 168 request. 170 While the burden cause by such requests is not dependent on a forged 171 IP source address, the use of such addresses makes 172 + the source of the requests causing the denial-of-service requests 173 to be harder to find and 174 + administrative restriction of the IP addresses from which such 175 requests should be honored harder to enforce. 177 2.1.2 Selected Host Denial-of-Service 179 Request with a forged IP address causes a response to be sent to that 180 forged IP address. Thus the forging of many such requests can, 181 indirectly, result in enough traffic being sent to the forged IP 182 address to interfere with service to the host at the IP address. 183 Furthermore, it is generally easy in the DNS to create short requests 184 that produce much longer responses. Thus a DNS server can be used as 185 not only a way to obscure the true source of an attack but as a 186 traffic amplifier to make the attack more effective. 188 Use of DNS cookies severely limits the traffic amplification that can 189 be obtained by attackers off path for the server and the attacked 190 host. Enforced DNS cookies would make it hard for an off path 191 attacker to cause any more than a brief error response to be send to 192 a forged IP address. Furthermore, DNS cookies make it more effective 193 to implement a rate limiting scheme for bad DNS cookie error response 194 from the server. Such a scheme would further restrict selected host 195 denial-of-service traffic from that server. 197 2.2 Cache Poisoning Attacks 199 The form of the cache poisoning attacks considered is to send forged 200 replies to a resolver. Modern network speeds for well connected hosts 201 are such that, by forging replies from the IP addresses of heavily 202 used DNS servers and for popular names to a heavily used resolver, 203 there can be an unacceptably high probability of randomly coming up 204 with a reply that will be accepted and cause false DNS information to 205 be cached by that resolver. This can be used to facilitate phishing 206 attacks and other diversion of legitimate traffic to a compromised or 207 malicious host such as a web server. 209 3. Comments on Existing DNS Security 211 Two forms of security have been added to DNS: 213 The first, called DNSSEC and described in [RFC4033], [RFC4034], and 214 [RFC4035], provides data origin authentication and authenticated 215 denial of existence. It is being deployed very slowly and, in any 216 case, can make some denial-of-service attacks worse because of the 217 high cryptographic computational load it can require and the 218 increased size in DNS packets that it can produces. 220 The second form of security which has been added to DNS provides 221 "transaction" security through TSIG [RFC2845] or SIG(0) [RFC2931]. 222 TSIG could provide near perfect protection against the attacks for 223 which DNS cookies provide weak and incomplete protection; however, 224 TSIG is hard to deploy in the general Internet because of the burden 225 it imposes of pre-agreement and key distribution between pairs of 226 resolvers and servers and because it requires time synchronization 227 between resolver and server. 229 TKEY [RFC2930] can solve the problem of key distribution for TSIG but 230 some modes of TKEY impose substantial cryptographic computations 231 loads and can be dependent on the deployment of DNSSEC. 233 SIG(0) provides less protection than TSIG or, in one way, even DNS 234 cookies, because it does not authentication requests, only complete 235 transactions. In any case, it also depends on the deployment of 236 DNSSEC and requires computationally burdensome public key 237 cryptographic operations. 239 Thus, none of the previous forms of DNS security are a suitable 240 substitute for DNS cookies, which provide light weight transaction 241 authentication of DNS requests and responses with no requirement for 242 pre-configuration. 244 4. The COOKIE OPT option 246 COOKIE is an OPT RR [RFC2671] option that can be included once in the 247 RDATA portion of an OPT RR in DNS requests and responses. 249 The option is encoded into 22 bytes as shown below. 251 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | OPTION-CODE TBD | OPTION-LENGTH = 18 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Resolver Cookie upper half | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Resolver Cookie lower half | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Server Cookie upper half | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Server Cookie lower half | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Error Code | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 The Resolver and Server Cookies are stored in network byte order and 268 are determined as described below. 270 The Error Code field MUST BE zero in requests and in responses unless 271 the response is communicating a DNS cookie error. Three values are 272 possible for Error Code: NOCOOKIE and BADCOOKIE which occur with a 273 Refused RCODE in the DNS response header, and MANYCOOKIE which occurs 274 with a FormErr RCODE in the DNS header. More information on the 275 generation of error response appears in Section 5 below. 277 4.1 Resolver Cookies 279 The Resolver Cookie, when it occurs in an OPT in a DNS response, is 280 intended to weakly assure the resolver that the response came from a 281 server at the indicated source IP address. 283 Servers remember the Resolver Cookie that appears in a query long 284 enough to use it in the construction of the COOKIE OPT option in the 285 corresponding response if such a COOKIE OPT option is included in 286 that response. 288 The Resolver Cookie SHOULD be a pseudo-random function of the server 289 IP address and a secret quantity known only to the resolver. This 290 resolver secret SHOULD have 64 bits of entropy [RFC4086] and MAY be 291 changed periodically. The RECOMMENDED method is the HMAC-MD5-64 292 [RFC1321], [RFC2104] of the server IP address and the resolver 293 secret. That is 295 Resolver Cookie = 296 Truncate-64 ( HMAC-MD5 ( Server IP, Resolver Secret ) ) 298 A resolver MUST NOT use the same Resolver Cookie value for queries to 299 all servers. 301 4.2 Server Cookies 303 The Server Cookie, when it occurs in a COOKIE OPT option in a query, 304 is intended to weakly assure the server that the query legitimately 305 came from a resolver at the indicated source IP address that is using 306 the indicated Resolver Cookie. 308 Resolvers learn Server Cookies and retain them as soft state 309 associated with the server IP address. They learn them from the 310 Server Cookie that appears in the COOKIE OPT option of a reply that 311 also has the correct Resolver Cookie, even if that reply is an error 312 message. 314 The Server Cookie SHOULD be a pseudo-random function of the request 315 source IP address, the request Resolver Cookie, and a secret quantity 316 known only to the server. This server secret SHOULD have 64 bits of 317 entropy [RFC4086] and SHOULD be changed periodically such as daily. 318 The RECOMMENDED method is the HMAC-MD5-64 [RFC1321], [RFC2104] of the 319 request IP address, the Resolver Cookie, and the server secret. That 320 is 322 Server Cookie = Truncate-64 ( 323 HMAC-MD5 ( (Request IP | Resolver Cookie), Server Secret ) ) 325 where "|" represents concatenation. 327 A server MUST NOT use the same Server Cookie value for responses to 328 all requests. 330 5. General Policies and Implementation 332 DNS resolvers and servers will adopt one of various policies 333 regarding cookies. These policies SHOULD be logically settable on a 334 per server IP address basis for resolvers and a per resolver ( IP 335 address, Resolver Cookie ) pair for servers. Thus a resolver can 336 have different policies for different servers, based on the server IP 337 address. And a server can have different policies for different 338 resolvers, based on the resolver IP address and Resolver Cookie. Of 339 course, the actual implementation of setting these policies may by 340 for blocks or classes of values or use sparse array techniques. 342 The policy for each value is either "Disabled", "Enabled", or 343 "Enforced" as described below. 345 5.1 Resolver Policies and Implementation 347 Disabled: 348 Never include a COOKIE RR in requests. 349 Ignore COOKIE OPT options in responses. 351 Enabled: 352 Always include an OPT RR with a COOKIE option in requests. If a 353 cached Server Cookie for the server is not available, the 354 Server Cookie field can be set to any value. 355 Normally process responses without a COOKIE OPT option. 356 Silently ignore responses with more than one COOKIE OPT option. 357 Silently ignore responses with one COOKIE OPT option if it has an 358 incorrect Resolver Cookie value. 359 On receipt of a response with one COOKIE OPT option and it having 360 the correct Resolver Cookie value (even if it is a BADCOOKIE 361 error response), perform normal response processing, including 362 caching the received Server Cookie and MUST change to the 363 Enforced policy for DNS requests to that server IP address. 364 This policy change SHOULD be treated as soft state with the 365 same discard policy as the Server Cookie value for that server. 366 On discarding that state information, the policy for that 367 server reverts to Enabled. 369 Enforced: 370 Always include a COOKIE OPT option in requests. 371 Silently ignore all responses that do not include exactly one 372 COOKIE OPT option with it having the correct Resolver Cookie 373 value. Normally process responses which do include such a 374 COOKIE OPT option. 376 5.2 Server Policies and Implementation 378 Disabled: 379 Ignore COOKIE OPT options in requests. 380 Never include a COOKIE OPT option in responses. 382 Enabled: 383 Normally process requests without a COOKIE OPT option. 384 Ignore, other than sending a MANYCOOKIE error response, any 385 request with more than one COOKIE OPT option. 386 Ignore, other than sending a BADCOOKIE error response, any query 387 with one COOKIE OPT option if it has an incorrect Server 388 Cookie. 389 On receipt of a request with a COOKIE OPT option having the 390 correct Server Cookie value, perform normal request processing 391 and SHOULD adopt the Enforced policy for DNS requests from that 392 resolver IP address with that Resolver Cookie in the request. 394 This policy change for that resolver SHOULD be treated as soft 395 state. On discarding that state information, the policy for 396 that resolver IP and Resolver Cookie pair reverts to enabled. 397 Always include a COOKIE OPT option in responses. 399 Enforced: 400 Ignore requests without a COOKIE OPT option or with more than one 401 COOKIE OPT option, other than sending a NOCOOKIE or MANYCOOKIE 402 error respectively. 403 Ignore requests with one COOKIE OPT option if they have an 404 incorrect Server Cookie, other than sending a BADCOOKIE error 405 message. 406 If a request has one COOKIE OPT option with a correct Server 407 Cookie, perform normal processing of the request. 408 Include a COOKIE OPT option in all responses. 410 5.3 Implementation Requirements 412 DNS resolvers and servers MUST implement DNS cookies. 414 DNS resolvers SHOULD operate in and be shipped so as to default to 415 the Enabled or Enforced mode for all servers. 417 DNS servers SHOULD operate in and be shipped so as to default to the 418 Enabled or Enforced mode for all resolvers they are willing to 419 service. 421 6. NAT and AnyCast Considerations 423 In the Classic Internet, DNS Cookies could simply be a pseudo-random 424 function of the resolver IP address and a sever secret or the server 425 IP address and a resolver secret. You would want to compute the 426 Server Cookie that way, so a resolver could cache its Server Cookie 427 for a particular server for an indefinitely amount of time and the 428 server could easily regenerate and check it. You could consider the 429 Resolver Cookie to be a resolver signature over the server IP address 430 which the resolver checks in responses and you could extend this 431 signature to cover the request ID, for example. 433 But we have this wart called NAT [RFC3022], Network Address 434 Translation (including therein for the purposes of this document NAT- 435 PT [RFC2766], Network Address and Protocol Translation). There is no 436 problem with DNS transactions between resolvers and servers behind a 437 NAT box using local IP addresses. Nor is there a problem with NAT 438 translation of internal addresses to external addresses or 439 translations between IPv4 and IPv6 addresses, as long as the address 440 mapping is relatively stable. Should an internal resolver being 441 mapped to a particular external IP address change occasionally, the 442 disruption is no more than when a resolver rolls-over its DNS COOKIE 443 secret. And normally external access to a DNS server behind a NAT box 444 is handled by a fixed mapping which forwards externally received DNS 445 requests to a specific host. 447 However, NAT devices sometimes also map ports. This can cause 448 multiple DNS requests and responses from multiple internal hosts to 449 be simultaneously mapped to a smaller number of external IP 450 addresses, frequently one. There could be many resolvers behind a 451 NAT box that appear to come from the same source IP address to a 452 server outside that NAT box.. If one of these were an attacker 453 (think Zombie or Botnet), that behind-NAT attacked could get the 454 Server Cookie for some server for the outgoing IP address by just 455 making some random request to that server. It could then include that 456 Server Cookie in the COOKIE RR of requests to the server with the 457 forged IP address of the local IP address of some other host and/or 458 resolver behind the NAT box. (Attacker possession of this Server 459 Cookie will not help in forging responses to cause cache poisoning as 460 such responses are protected by the required Resolver Cookie.) 462 To fix this potential defect, it is necessary to distinguish 463 different resolvers behind a NAT box from the point of view of the 464 server. It is for this reason that the Server Cookie is specified as 465 a pseudo-random function of both the request source IP address and 466 the Resolver Cookie. From this inclusion of the Resolver Cookie in 467 the calculation of the Server Cookie, it follows that a stable 468 Resolver Cookie, for any particular server, is needed. If, for 469 example, the request ID was included in the calculation of the 470 Resolver Cookie, it would normally change with each query to a 471 particular server. This would mean that each query would have to be 472 sent twice: first to learn the new Server Cookie based on this new 473 Resolver Cookie based on the new ID and then again using this new 474 Resolver Cookie to actually get an answer. Thus the input to the 475 Resolver Cookie computation must be limited to the server IP address 476 and one or more things that change slowly such as the resolver 477 secret. 479 In principle, there could be a similar problem for servers, not 480 particularly due to NAT but due to mechanisms like anycast which may 481 cause queries to a DNS server at an IP address to be delivered to any 482 one of several machines. (External queries to a DNS server behind a 483 NAT box usually occur via port forwarding such that all such queries 484 go to one host.) However, it is impossible to solve this the way the 485 similar problem was solved for NATed resolvers; if the Server Cookie 486 was included in the calculation of the Resolver Cookie the same way 487 the Resolver Cookie is included in the Server Cookie, you would just 488 get an almost infinite series of BADCOOKIE errors as a query was 489 repeatedly retried. 491 For server accessed via anycast or similar mechanisms to successfully 492 support DNS COOKIES, the server clones must either all use the same 493 server secret or the mechanism that distributes queries to them must 494 cause the queries from a particular resolver to go to a particular 495 server for a sufficiently long period of time that extra queries due 496 to changes in Server Cookie resulting from accessing different server 497 machines are not unduly burdensome. When such anycast accessed 498 servers act as recursive servers or otherwise act as resolvers they 499 normally use a different unique address to source their queries and 500 avoid confusion in the delivery of responses. 502 For simplicity, it is recommended that the same server secret be used 503 by each set of anycast servers. 505 7. IANA Considerations 507 The OPT option value for COOKIE is TBD. 509 Three new RCODES are assigned values above 15: 510 NOCOOKIE is assigned the value (TBD, 23 suggested). 511 BADCOOKIE is assigned the value (TBD, 24 suggested). 512 MANYCOOKIE is assigned the value (TBD, 25 suggested). 514 8. Security Considerations 516 DNS Cookies provide a weak form of authentication of DNS requests and 517 responses. In particular, they provide no protection at all against 518 "on-path" adversaries; that is, they provide no protection against 519 any adversary which can observe the plain text DNS traffic, such as 520 an on-path router, bridge, or any device on an on-path shared link 521 (unless the DNS traffic in question on that path is appropriately 522 encrypted). 524 For example, if a host is connected via an unsecured IEEE 802.11 link 525 (Wi-Fi), any device in the vicinity that could receive and decode the 526 802.11 transmissions must be considered "on-path". On the other hand, 527 in a similar situation but one where 802.11i security is 528 appropriately deployed on the Wi-Fi network nodes, only the Access 529 Point via which the host is connecting is "on-path". 531 Despite these limitations, use of DNS Cookies on the global Internet 532 are expected to provide a reduction in the available launch points 533 for the traffic amplification and denial of service attacks described 534 in Section 2 above. 536 The recommended cryptographic algorithm for use in DNS Cookies is 537 HMAC-MD5-64, that is, the HMAC scheme [RFC2104] using the MD5 hash 538 function [RFC1321] with its output truncated to 64-bits. Although MD5 539 is now considered to be susceptible to collisions attacks, this does 540 not effect the security of HMAC-MD5. 542 In light of the weak plain-text token security provided by DNS 543 Cookies, stronger cryptography is probably not warranted. However, 544 there is nothing wrong with using, for example, HMAC-SHA256-64 545 instead, assuming a DNS processor has adequate computational 546 resources available. DNS processors that feel the need for somewhat 547 stronger security without a significant increase in computational 548 load should consider more frequent changes in their resolver and/or 549 server secret; however, this does require more frequent generation of 550 a cryptographically strong random number [RFC4086] and a change in a 551 server secret will result in a number of BADCOOKIE rejected requests 552 from resolvers caching their old Server Cookie. 554 9. Copyright and Disclaimer 556 Copyright (C) The Internet Society (2006). 558 This document is subject to the rights, licenses and restrictions 559 contained in BCP 78, and except as set forth therein, the authors 560 retain all their rights. 562 This document and the information contained herein are provided on an 563 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 564 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 565 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 566 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 567 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 568 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 570 10. Normative References 572 [RFC1321] - Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 573 April 1992. 575 [RFC2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 576 Hashing for Message Authentication", RFC 2104, February 1997. 578 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, March 1997. 581 [RFC2181] - Elz, R. and R. Bush, "Clarifications to the DNS 582 Specification", RFC 2181, July 1997. 584 [RFC2671] - Vixie, P., "Extension Mechanisms for DNS (EDNS0)", August 585 1999. 587 [RFC4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, 588 "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 590 [STD13] 591 Mockapetris, P., "Domain names - concepts and facilities", STD 592 13, RFC 1034, November 1987. 594 Mockapetris, P., "Domain names - implementation and 595 specification", STD 13, RFC 1035, November 1987. 597 11. Informative References. 599 [RFC2766] - Tsirtsis, G., P. Srisuresh"Network Address Translation - 600 Protocol Translation (NAT-PT)", February 2000. 602 [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 603 Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", 604 RFC 2845, May 2000. 606 [RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 607 RR)", RFC 2930, September 2000. 609 [RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures 610 ( SIG(0)s )", RFC 2931, September 2000. 612 [RFC3022] - Srisuresh, P. and K. Egevang, "Traditional IP Network 613 Address Translator (Traditional NAT)", RFC 3022, January 2001. 615 [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 616 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 617 2005. 619 [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 620 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 621 March 2005. 623 [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 624 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 625 4035, March 2005. 627 Author's Address 629 Donald E. Eastlake 3rd 630 Motorola Laboratories 631 111 Locke Drive 632 Marlborough, MA 01752 USA 634 Telephone: +1-508-786-7554 (w) 636 EMail: Donald.Eastlake@motorola.com 638 Additional IPR Provisions 640 The IETF takes no position regarding the validity or scope of any 641 Intellectual Property Rights or other rights that might be claimed 642 to pertain to the implementation or use of the technology 643 described in this document or the extent to which any license 644 under such rights might or might not be available; nor does it 645 represent that it has made any independent effort to identify any 646 such rights. Information on the procedures with respect to 647 rights in RFC documents can be found in BCP 78 and BCP 79. 649 Copies of IPR disclosures made to the IETF Secretariat and any 650 assurances of licenses to be made available, or the result of an 651 attempt made to obtain a general license or permission for the use 652 of such proprietary rights by implementers or users of this 653 specification can be obtained from the IETF on-line IPR repository 654 at http://www.ietf.org/ipr. 656 The IETF invites any interested party to bring to its attention 657 any copyrights, patents or patent applications, or other 658 proprietary rights that may cover technology that may be required 659 to implement this standard. Please address the information to the 660 IETF at ietf-ipr@ietf.org. 662 Expiration and File Name 664 This draft expires in April 2007. 666 Its file name is draft-eastlake-dnsext-cookies-01.txt