idnits 2.17.1 draft-yan-dprive-local-service-indication-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (December 13, 2020) is 1230 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4339 ** Downref: Normative reference to an Experimental RFC: RFC 8094 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dprive Working Group Z. Yan 3 Internet-Draft CNNIC 4 Intended status: Standards Track G. Geng 5 Expires: June 16, 2021 Jinan University 6 Y. Liu 7 CAICT 8 X. Zhang 9 Shandong Computer Science Center 10 X. Zhu 11 Shandong Institute of Big Data 12 December 13, 2020 14 Indication of Local DNS Privacy Service During User Access 15 draft-yan-dprive-local-service-indication-04 17 Abstract 19 This document aims to support the indication of privacy service 20 capability of recursive resolver during the end-user accesses the 21 network. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119] 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 16, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. ICMPv6 based case . . . . . . . . . . . . . . . . . . . . . . 2 65 3. DHCPv6 based case . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Security considerations . . . . . . . . . . . . . . . . . . . 3 67 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 In order to enhance the privacy protection in DNS, several solutions 74 have been developed to support the encrypted communications between 75 stub and recursive resolvers, such as DNS-over-DTLS [RFC8094], DNS- 76 over-TLS [RFC7858], DNS-over-QUIC and so on. However, a scheme is 77 needed in order to explicitly make the end-user (stub resovler) be 78 aware of the types of privacy service supported by the recursive 79 resolver in order to avoid the blind attempt by the end-user and 80 support the user to bootstrap the preferred privacy protocol more 81 easily. This can be achieved during the user initial access, using 82 extended DHCPv6 or ICMPv6 to configure its recursive resolver with 83 related information (only IPv6 scenario is considered herein). 85 2. ICMPv6 based case 87 The "Recursive DNS Server Option" is defined in [RFC8106] to support 88 the user to configure DNS recursive resolver in the IPv6 SLAAC mode. 89 Then a 4-bit (for example) space (denoted as "Cap." field) in the 90 Reserved field of "Recursive DNS Server Option" can be used to 91 indicate the privacy service of the corresponding recursive resolver 92 specified in the field of "Addresses of IPv6 Recursive DNS Servers". 93 However, if this function is used, the "Addresses of IPv6 Recursive 94 DNS Servers" should contain only the recursive resolver(s) with the 95 same privacy service capability indicated by the corresponding "Cap." 96 field. How to code the "Cap." field will be detailed further. 98 3. DHCPv6 based case 100 The "DNS Recursive Name Server option" is defined in [RFC3646] to 101 support the user to configure DNS recursive resolver in the IPv6 DHCP 102 [RFC4339] mode. However, [RFC3646] did not reserve extra space, a 103 new option should be defined which is conjunctively used with "DNS 104 Recursive Name Server option". It is defined as "DNS Recursive 105 Server Privacy option" and the format is shown in Figure 1. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | OPTION_DNS_SERVERS_PRIVACY | option-len | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Cap. | Cap. |...... | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Figure 1: DNS Recursive Server Privacy option 117 o option-code: OPTION_DNS_SERVERS_PRIVACY 119 o option-len: Length of the list of privacy service capability of 120 DNS recursive name servers in octets; must be a multiple of 4 (for 121 example). 123 o Capability: The 4-bit (for example) space (denoted as "Cap." 124 field) is used to indicate the privacy service of the 125 corresponding recursive resolver specified in the field of DNS- 126 recursive-name-server in the DNS Recursive Name Server option. 128 The DNS Recursive Server Privacy option should be used conjunctively 129 with the DNS Recursive Name Server option and the order of "Cap." 130 fields in the DNS Recursive Server Privacy option must be 131 corresponding to the server order specified in the DNS Recursive Name 132 Server option. 134 4. Security considerations 136 TBA 138 5. Normative References 140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 141 Requirement Levels", BCP 14, RFC 2119, 142 DOI 10.17487/RFC2119, March 1997, 143 . 145 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 146 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 147 DOI 10.17487/RFC3646, December 2003, 148 . 150 [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server 151 Information Approaches", RFC 4339, DOI 10.17487/RFC4339, 152 February 2006, . 154 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 155 and P. Hoffman, "Specification for DNS over Transport 156 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 157 2016, . 159 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 160 Transport Layer Security (DTLS)", RFC 8094, 161 DOI 10.17487/RFC8094, February 2017, 162 . 164 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 165 "IPv6 Router Advertisement Options for DNS Configuration", 166 RFC 8106, DOI 10.17487/RFC8106, March 2017, 167 . 169 Appendix A. Acknowledgments 171 This work was supported by Beijing Nova Program of Science and 172 Technology under grant Z191100001119113. 174 Authors' Addresses 176 Zhiwei Yan 177 CNNIC 178 No.4 South 4th Street, Zhongguancun 179 Beijing 100190 180 China 182 EMail: yan@cnnic.cn 184 Guanggang Geng 185 Jinan University 186 No.601, West Huangpu Avenue 187 Guangzhou 510632 188 China 190 EMail: gggeng@jnu.edu.cn 192 Yang Liu 193 CAICT 194 No.52, Huayuanbeilu 195 Beijing 100191 196 China 198 EMail: liuyang7@caict.ac.cn 200 Xinchang Zhang 201 Shandong Computer Science Center 202 No.19 Keyuan Road, Lixia District 203 Jinan, 250014 204 P.R. China 206 EMail: xincha.zhang@gmail.com 207 Xiaomin Zhu 208 Shandong Institute of Big Data 209 7/F, building 7, Shun Tai Plaza, No.2000, Shun Hua Road, hi-tech Zone 210 Jinan, 250014 211 P.R. China 213 EMail: zhuxiaomin@ict.ac.cn