idnits 2.17.1 draft-bellis-dnsop-edns-tags-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2019) is 1860 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group R. Bellis 3 Internet-Draft A. Clegg 4 Intended status: Standards Track ISC 5 Expires: September 26, 2019 P. van Dijk 6 PowerDNS 7 March 25, 2019 9 DNS EDNS Tags 10 draft-bellis-dnsop-edns-tags-01 12 Abstract 14 This document describes EDNS Tags, a mechanism by which DNS clients 15 and servers can transmit an opaque data field which has no defined 16 semantic meaning other than as previously agreed between the client 17 and server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 26, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Packet Validation Rules . . . . . . . . . . . . . . . . . 3 57 3.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 3 58 3.3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.3.1. EDNS-Client-Tag . . . . . . . . . . . . . . . . . . . 4 60 3.3.2. EDNS-Server-Tag . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 5. Implementation status . . . . . . . . . . . . . . . . . . . . 5 63 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 This document describes EDNS Tags, a mechanism by which DNS clients 72 and servers [RFC1034] can transmit an opaque data field which has no 73 defined semantic meaning other than as previously agreed between the 74 client and server operators. 76 The tag is a single 16 bit field stored within the RDATA of an 77 EDNS(0) OPT RR as described in [RFC6891]. 79 Two EDNS options are defined to allow for the detection of servers 80 that incorrectly echo responses verbatim. The EDNS-Client-Tag option 81 may only appear in client requests, and the EDNS-Server-Tag may only 82 appear in responses from servers. 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in BCP 89 14 [RFC2119] [RFC8174] when, and only when, they appear in all 90 capitals, as shown here. 92 3. Description 94 The values of the individual bits within a tag are not defined to 95 have any semantic meaning in this specification. Their 96 interpretation is defined entirely by out-of-band bilateral agreement 97 between client and server operators. 99 Operators are free to partition the bits within that field as they 100 see fit; for example it could be used to transmit up to 16 separate 101 boolean flags, or perhaps to transmit a 10 bit numeric value combined 102 a 2 bit value and four boolean flags. 104 The intended mode of operation is that the value of a bit (or range 105 of bits) could be tested in access control lists or any other such 106 policy control mechanism. 108 Possible use cases for EDNS-Client-Tags include: 110 o client-controlled selection of a DNS-based security filter 112 o marking a packet passing through a proxy with transport-related 113 information 115 Use cases for EDNS-Server-Tags are still to be determined. The 116 option is specified here for symmetry and in anticipation of new use 117 cases being discovered. The semantic definitions for EDNS-Client-Tag 118 and EDNS-Server-Tag values MAY be different; they need not be 119 symmetrical. 121 3.1. Packet Validation Rules 123 The OPT RR in a DNS request packet (QR = 0) MUST NOT contain an EDNS- 124 Server-Tag option. A request packet MUST NOT contain more than one 125 EDNS-Client-Tag option. 127 The OPT RR in a DNS response packet (QR = 1) MUST NOT contain an 128 EDNS-Client-Tag option. A response packet MUST NOT contain more than 129 one EDNS-Server-Tag option. 131 An EDNS-Server-Tag option MUST NOT be sent unless the corresponding 132 client query contained an EDNS-Client-Tag option. 134 3.2. Error Handling 136 Clients MUST discard any response packet that breaches any applicable 137 packet validation rule. 139 Servers MUST respond with a FORMERR in accordance with Section 7 of 140 [RFC6891] on receipt of a request that breaches any applicable packet 141 validation rule. 143 3.3. Wire Format 145 The format of the EDNS options are as follows, to be stored within 146 the RDATA of an OPT RR as specified in [RFC6891]: 148 3.3.1. EDNS-Client-Tag 150 +0 (MSB) +1 (LSB) 151 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 152 0: | OPTION-CODE (TBD1) | 153 +---+---+---+---+---+---+---+---|---+---+---+---+---+---+---+---+ 154 2: | OPTION-LENGTH (2) | 155 +---+---+---+---+---+---+---+---|---+---+---+---+---+---+---+---+ 156 4: | CLIENT-TAG-DATA | 157 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 159 OPTION-CODE: The option code identifier (TBD1). 161 OPTION-LENGTH: Size (in octets) of OPTION-DATA. MUST be 2. 163 CLIENT-TAG-DATA: The tag field sent from client to server. 165 3.3.2. EDNS-Server-Tag 167 +0 (MSB) +1 (LSB) 168 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 169 0: | OPTION-CODE (TBD2) | 170 +---+---+---+---+---+---+---+---|---+---+---+---+---+---+---+---+ 171 2: | OPTION-LENGTH (2) | 172 +---+---+---+---+---+---+---+---|---+---+---+---+---+---+---+---+ 173 4: | SERVER-TAG-DATA | 174 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 176 OPTION-CODE: The option code identifier (TBD2). 178 OPTION-LENGTH: Size (in octets) of OPTION-DATA. MUST be 2. 180 SERVER-TAG-DATA: The tag field sent from server to client. 182 4. Security Considerations 184 Client tags are under the control of the client software and as such 185 (and in the absence of any other mechanism to authenticate the 186 client's identity) this mechanism is not appropriate for applications 187 where the DNS server operator wishes to contractually differentiate 188 service based on the interpretation of the tag's value. 190 5. Implementation status 192 TBC. 194 6. Privacy Considerations 196 Tags are opaque fields that encode only a limited amount of 197 information. The size of the data field in this specification is 198 chosen to offer a compromise between offering sufficient content to 199 be technically useful while also limiting the scope for it to be used 200 to transmit Personally Identifiable Information. 202 7. IANA Considerations 204 IANA has assigned the following EDNS(0) Option Codes: 206 Value Name Status Reference 207 ---------------------------------------------------------- 208 TBD1 EDNS-Client-Tag Standard RFCXXXX 209 TBD2 EDNS-Server-Tag Standard RFCXXXX 211 << Note to IANA - please assign an even value to TBD1, and the next 212 consecutive odd value to TBD2. This allows the least-significant bit 213 of the option value to be compared against the packet's QR bit >> 215 8. Acknowledgements 217 The authors wish to particularly thank Brian Conry, Peter van Dijk 218 and Matthijs Mekking for early review and feedback on this document. 220 9. Normative References 222 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 223 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 224 . 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, 228 DOI 10.17487/RFC2119, March 1997, 229 . 231 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 232 for DNS (EDNS(0))", STD 75, RFC 6891, 233 DOI 10.17487/RFC6891, April 2013, 234 . 236 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 237 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 238 May 2017, . 240 Authors' Addresses 242 Ray Bellis 243 Internet Systems Consortium, Inc. 244 950 Charter Street 245 Redwood City CA 94063 246 USA 248 Phone: +1 650 423 1200 249 Email: ray@isc.org 251 Alan Clegg 252 Internet Systems Consortium, Inc. 253 950 Charter Street 254 Redwood City CA 94063 255 USA 257 Phone: +1 650 423 1200 258 Email: aclegg@isc.org 260 Peter van Dijk 261 PowerDNS.COM B.V. 262 Den Haag 263 The Netherlands 265 Email: peter.van.dijk@powerdns.com