idnits 2.17.00 (12 Aug 2021) /tmp/idnits63306/draft-barwood-dnsext-edns-page-option-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 August 2009) is 4652 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group G. Barwood 3 Internet-Draft 4 Intended status: Standards track 25 August 2009 5 Expires: February 2010 7 EDNS Page Option 8 draft-barwood-dnsext-edns-page-option-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on February 26, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Describes an EDNS option to allow large DNS responses to be sent 47 using small UDP packets. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 Initial request . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2 Server response . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3 Follow-up request . . . . . . . . . . . . . . . . . . . . . 5 61 3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 DNSSEC implies that DNS responses may be large, possibly larger than the 74 de facto ~1500 byte internet MTU. The IP protocol specifies a means by 75 which large IP packets are split into fragments and then re-assembled. 77 Fragmented UDP responses are undesirable for several reasons: 79 (1) Fragments can easily be spoofed. The DNS ID and port number are only 80 present in the first fragment, and the IP ID is usually easy for an 81 attacker to predict. 83 (2) In practise fragmentation is not reliable, and large UDP packets may 84 fail to be delivered. 86 (3) If a single fragment is lost, the entire response must be re-sent. 88 (4) Re-assembling fragments requires buffer resources, which opens 89 up denial of service attacks. 91 Instead, it is possible to use TCP for large responses, but this is 92 undesirable, as TCP imposes significant overhead and state that may 93 be vulnerable to denial of service attack. 95 Nearly all current DNS traffic is carried by UDP with a maximum size of 96 512 bytes, and relying on TCP is a risk for the deployment of DNSSEC. 98 A particular problem occurs with DNS proxies, which often truncate 99 responses at 512 bytes. In this case, TCP does not help, and it is 100 impossible to retrieve responses through the proxy. 102 Therefore an EDNS option [RFC2181] to allow large DNS responses to be 103 sent using small UDP packets is proposed. 105 The option includes an authentication mechanism that prevents blind 106 spoofing of the response, provided IP fragmentation does not occur. 108 2. Protocol 110 Reserved areas and undefined bits must be set to zero length / zero by 111 the sender and must be ignored by the receiver. 113 2.1 Initial request 115 The client signals support in it's initial request by including 116 an EDNS Page option with option data : 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |0|A| | UDPMAX | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | EXTID | 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 / RESERVED / 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 where : 129 A is a 1 bit field set to request that the server send all 130 pages immediately. It must not be used with proxy servers 131 that do not support it, except for discovery. The server 132 may decline the request. 134 UDPMAX is a 12 bit field that limits the UDP payload of response 135 packets. Commonly set to 512, as proxies often limit 136 responses to the RFC 1035 UDP limit. The minimum value 137 is 512. 139 EXTID is a 32 bit field used to validate the response, preventing 140 blind spoofing. 142 2.2 Server response 144 The server responds with an EDNS Page option. The server does not send 145 a copy of the question. The Page option data is : 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |A|N| | PAGESIZE | TOTAL | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | EXTID | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | COOKIE | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | PAGE | / 155 +-+-+-+-+-+-+-+-+ / 156 / DATA / 157 / / 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 where : 162 A is a 1 bit field set to indicate that all pages have 163 been sent. 165 N is a 1 bit field set to indicate that the cookie is omitted, 166 and follow-up requests are not possible. 168 PAGESIZE is a 12 bit field, the size of the pages into which the full 169 response is divided, chosen so that the UDP payload does not 170 exceed UDPMAX from the initial request. Servers may also 171 limit the UDP payload for other reasons, for example to 172 mitigate an amplification attack, or to avoid IP 173 fragmentation. 175 TOTAL is a 16 bit field, the size in bytes of the whole response. 177 EXTID is a copy of the EXTID from the request. The client must 178 check that the value is as expected. 180 COOKIE is a 32 bit field, used in follow-up requests. 182 PAGE is an 8 bit field. 184 DATA is a variable length field containg the page data. 186 The client allocates an assembly buffer of TOTAL bytes, and copies DATA 187 into it, at offset PAGE x PAGESIZE. 189 2.3 Follow-up request 191 If the A bit of the response is zero, the client sends a follow-up 192 request for each page it has not yet received. The client should also 193 send follow-up requests if an expected response is not received after 194 a timeout period due to packet loss. 196 A follow-up request is identical to the initial request, except 197 that the EDNS page option data is as follows: 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |1| | PAGESIZE | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | EXTID | 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | COOKIE | 206 | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | PAGE | / 209 +-+-+-+-+-+-+-+-+ / 210 / RESERVED / 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 where : 215 PAGESIZE is a copy of PAGESIZE in the response. 217 EXTID is a copy of EXTID in the initial request. 219 COOKIE is a copy of COOKIE from the response that identifies a 220 read-only representation of the full response on the server, 221 possibly in conjunction with the Question. The cookie has a 222 lifetime of 5 seconds. After this time has elapsed, a 223 SERVERFAIL error response may be generated. 225 PAGE identifies the required page. 227 When the client has received all of the pages, the complete assembled 228 response is then processed normally. 230 Follow-up requests may be sent in parallel. 232 3. Compatibility 234 Servers are not required to support the EDNS Page option, however 235 support is encouraged. 237 Authoritative servers that do not support the EDNS page option can 238 expect a higher level of TCP traffic. 240 Authoritative servers need not support cookies. Initial requests to 241 authoritative servers should normally set the A flag. However, cookie 242 support is encouraged, as it allows dropped packets to be retried 243 without re-sending the whole response. 245 DNSSEC aware recursive servers need to support cookies if they may 246 be accessed via proxy servers that truncate responses at 512 bytes. 248 DNSSEC validating stub resolvers need to use the EDNS Page option if 249 they may be deployed behind proxy servers that truncate responses at 250 512 bytes. 252 Firewalls may not allow multiple responses through, and servers 253 should detect this possibility, and disable multiple responses, 254 if the firewall cannot be re-configured. 256 4. Security Considerations 258 The EXTID may expose internal state to an attacker who controls a name 259 server. It is essential that a cryptographically strong source of random 260 numbers be used to generate the secret key. This must be seeded from 261 data that cannot be guessed by an attacker, such as thermal noise or 262 other random physical fluctuations. 264 Clients must verify the EXTID in each response. 266 Fragmented responses are vulnerable to blind spoofing, therefore 267 fragmented responses should be avoided if possible. 269 If the response does not have a Page Option, to avoid a potential 270 spoofing downgrade attack the client may send an additional query, 271 or adopt other measures to prevent blind spoofing that are outside the 272 scope of this document. 274 To limit the effectiveness of amplification attacks on third parties, 275 servers should make every effort to limit the maximum number of 276 packets that are sent in response to a single query. 278 Suggested techniques include: 280 - Declining requests to send all pages when QTYPE=ANY. 282 - Not sending the NS RRset when QTYPE=DNSKEY. 284 - Limiting additional section processing so that it does not 285 contribute to the maximum response. 287 - Checking that UDPMAX in the initial request is at least 512. 289 5. IANA Considerations 291 The EDNS TYPE code for Page Option. 293 6. Acknowledgments 295 Mark Andrews, Alex Bligh, Robert Elz, Douglas Otis, 296 Wouter Wijngaards, Nicholas Weaver were each instrumental in 297 creating and refining this specification. 299 7. Informative References 301 [RFC2181] P. Vixie, "Extension Mechanisms for DNS (EDNS0)", 302 RFC 2181, August 1999. 304 Author's Address 306 George Barwood 307 33 Sandpiper Close 308 Gloucester 309 GL2 4LZ 310 United Kingdom 312 Phone: +44 452 722670 313 EMail: george.barwood@blueyonder.co.uk