idnits 2.17.1 draft-uberti-rtcweb-ip-handling-ex-mdns-00.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 (November 03, 2018) is 1995 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB J. Uberti 3 Internet-Draft J. de Borst 4 Intended status: Informational Q. Wang 5 Expires: May 7, 2019 Google 6 Y. Fablet 7 Apple Inc. 8 November 03, 2018 10 WebRTC IP Address Handling Extensions for Multicast DNS 11 draft-uberti-rtcweb-ip-handling-ex-mdns-00 13 Abstract 15 This document extends the previous WebRTC IP Address Handling 16 Requirements with new modes that make use of Multicast DNS ICE 17 candidates, and updates the recommendations accordingly. 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 May 7, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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. New Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3.1. Mode 2.1 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Mode 2.2 . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Additional Applications . . . . . . . . . . . . . . . . . . . 3 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 8.2. Informative References . . . . . . . . . . . . . . . . . 4 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 67 1. Introduction 69 [IPHandling] describes the privacy problems associated with exposing 70 IP addresses to web applications, but admits that there is no 71 solution to the issue of exposing private IP addresses that does not 72 carry a corresponding impact on connectivity. 74 [mDNSCandidates] introduces a new technique based on Multicast DNS 75 (mDNS) that obscures private IP addresses with mDNS names. This 76 solves the privacy issues associated with exposing local IP 77 addresses, and mitigates most of the aforementioned connectivity 78 impact. 80 This document extends the set of modes defined in [IPHandling] with 81 new options based on the mDNS technique. Different choices are 82 provided, each with their own benefits and drawbacks. 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 3. New Modes 92 Using the mDNS technique, we define two new modes, namely Mode 2.1 93 and 2.2. These modes are identical to Mode 2 from [IPHandling], but 94 the technique from [mDNSCandidates] is used to protect the selected 95 private IP addresses. Accordingly, the privacy guidelines outlined 96 in [mDNSCandidates], Section 5 MUST be followed in each new mode in 97 order to prevent accidental disclosure of a private IP address. 99 3.1. Mode 2.1 101 The local IPv4 address associated with the preferred interface MUST 102 be replaced with a mDNS name, as described in [mDNSCandidates], 103 Section 3.1. Any local IPv6 addresses associated with the preferred 104 interface MUST also be replaced with mDNS names, unless they are 105 [RFC4941] privacy-preserving addresses. 107 3.2. Mode 2.2 109 All local IPv4 and IPv6 addresses MUST be replaced with mDNS names, 110 as described in [mDNSCandidates], Section 3.1. 112 4. Analysis 114 The only difference between Mode 2.1 and Mode 2.2 is how [RFC4941] 115 addresses are handled. In either case, a direct connection is 116 possible if the mDNS addresses created for the local IP addresses can 117 be resolved. However, when mDNS fails, either because it is disabled 118 on the network, or the endpoints are not on the same segment, Mode 119 2.1 may allow a direct connection where Mode 2.2 does not. 121 The exact impact on applications needs to be determined 122 experimentally. This document will be updated with a specific 123 recommendation once this information is known. 125 5. Additional Applications 127 The mDNS technique may also have value even when all network 128 interfaces are used by the ICE agent, i.e., in Mode 1 from 129 [IPHandling], by minimizing the amount of information regarding the 130 local network that is disclosed to the remote peer. Accordingly, a 131 future update of this document may define additional modes that apply 132 the mDNS technique to Mode 1. This is an area for further study. 134 6. Security Considerations 136 The modes defined here, on their own, present no new security 137 considerations. Considerations for the mDNS technique are detailed 138 in [mDNSCandidates], Section 6. 140 7. IANA Considerations 142 This document requires no actions from IANA. 144 8. References 146 8.1. Normative References 148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 149 Requirement Levels", BCP 14, RFC 2119, 150 DOI 10.17487/RFC2119, March 1997, 151 . 153 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 154 Extensions for Stateless Address Autoconfiguration in 155 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 156 . 158 8.2. Informative References 160 [IPHandling] 161 Shieh, G., "WebRTC IP Address Handling Requirements", 162 April 2018, . 165 [mDNSCandidates] 166 Wang, Q., "Using Multicast DNS to protect privacy when 167 exposing ICE candidates", October 2018, 168 . 171 Authors' Addresses 173 Justin Uberti 174 Google 176 Email: juberti@google.com 178 Jeroen de Borst 179 Google 181 Email: jeroendb@google.com 182 Qingsi Wang 183 Google 185 Email: qingsi@google.com 187 Youenn Fablet 188 Apple Inc. 190 Email: youenn@apple.com