idnits 2.17.1 draft-winfaa-intarea-broadcast-consider-03.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 (September 15, 2016) is 2780 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-intarea-hostname-practice-00 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Winter 3 Internet-Draft M. Faath 4 Intended status: Informational F. Weisshaar 5 Expires: March 19, 2017 University of Applied Sciences Augsburg 6 September 15, 2016 8 Privacy considerations for IP broadcast and multicast protocol designers 9 draft-winfaa-intarea-broadcast-consider-03 11 Abstract 13 A number of application-layer protocols make use of IP broadcasts or 14 multicast messages for functions such as local service discovery or 15 name resolution. Some of these functions can only be implemented 16 efficiently using such mechanisms. When using broadcasts or 17 multicast messages, a passive observer in the same broadcast domain 18 can trivially record these messages and analyze their content. 19 Therefore, broadcast/multicast protocol designers need to take 20 special care when designing their protocols. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 19, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Privacy considerations . . . . . . . . . . . . . . . . . . . 3 59 2.1. Message frequency . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Persistent identifiers . . . . . . . . . . . . . . . . . 4 61 2.3. Anticipate user behavior . . . . . . . . . . . . . . . . 4 62 2.4. Consider potential correlation . . . . . . . . . . . . . 5 63 2.5. Configurability . . . . . . . . . . . . . . . . . . . . . 5 64 3. Operational considerations . . . . . . . . . . . . . . . . . 6 65 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Other considerations . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 9. Informative References . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Broadcast and multicast messages have a large (and to the sender 76 unknown) receiver group by design. Because of that, these two 77 mechanisms are vital for a number of basic network functions such as 78 auto-configuration. Application developers use broadcast/multicast 79 messages to implement things like local service or peer discovery and 80 it appears that an increasing number of applications make use of it 81 [TRAC2016]. 83 Using broadcast/multicast can become problematic if the information 84 that is being distributed can be regarded as sensitive or when the 85 information that is distributed by multiple of these protocols can be 86 correlated in a way that sensitive data can be derived. This is 87 clearly true for any protocol, but broadcast/multicast is special in 88 at least two respects: 90 (a) The aforementioned large receiver group, consisting of receivers 91 unknown to the sender. This makes eavesdropping trivial for 92 anybody on a LAN without special privileges or a special 93 location in the network and 95 (b) encryption is more difficult when broadcasting/multicasting 96 messages, leaving content of these messages in the clear and 97 making it easier to spoof and replay these messages. 99 Given the above, privacy protection for protocols based on broadcast 100 or multicast communication is significantly more difficult compared 101 to unicast communication and at the same time invading the privacy is 102 much easier. 104 Privacy considerations of IETF-specified protocols have received some 105 attention in the recent past (e.g. [RFC7721] or [RFC7819]). There 106 is also general guidance available for document authors on when and 107 how to include a privacy considerations section in their documents 108 and on how to evaluate the privacy implications of Internet protocols 109 [RFC6973]. RFC6973 also describes potential threads to privacy in 110 great detail and lists terminology that is also used in this 111 document. 113 In contrast to RFC6973, this document contains a number of privacy 114 considerations especially for broadcast/multicast protocol designers 115 that are intended to reduce the likelihood that a broadcast protocol 116 can be misused to collect sensitive data about devices, users and 117 groups of users on a LAN. These considerations particularly apply to 118 protocols designed outside the IETF for two reasons. For one, non- 119 standard protocols will likely not receive operational attention and 120 support in making them more secure such as e.g. DHCP snooping does 121 for DHCP because they typically are not documented. The other reason 122 is that these protocols have been designed in isolation, where a set 123 of considerations to follow is useful in the absence of a larger 124 community providing feedback. In particular, carelessly designed 125 broadcast/multicast protocols can break privacy efforts at different 126 layers of the protocol stack such as MAC address or IP address 127 randomization [RFC4941]. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 2. Privacy considerations 137 There are a few obvious and a few not necessarily obvious things 138 designers of broadcast/multicast protocols should consider in respect 139 to the privacy implications of their protocol. Most of these items 140 are based on protocol behavior observed as part of experiments on 141 operational networks [TRAC2016]. 143 2.1. Message frequency 145 Frequent broadcast/multicast traffic caused by an application can 146 give user behavior and online times away. This allows a passive 147 observer to potentially deduce a user's current activity (e.g. a 148 game) and it allows to create an online profile (i.e. times the user 149 is on the network). The higher the frequency of these messages, the 150 more accurate this profile will be. Given that broadcasts are only 151 visible in the same broadcast domain, these messages also give the 152 rough location of the user away (e.g. a campus or building). 154 If a protocol relies on frequent or periodic broadcast/multicast 155 messages, the frequency SHOULD be chosen conservatively, in 156 particular if the messages contain persistent identifiers (see next 157 subsection). Also, intelligent message suppression mechanisms such 158 as the ones employed in mDNS [RFC6762] SHOULD be implemented. The 159 lower the frequency of broadcast messages, the harder traffic 160 analysis and surveillance becomes. 162 2.2. Persistent identifiers 164 A few broadcast/multicast protocols observed in the wild make use of 165 persistent identifiers. This includes the use of hostnames or more 166 abstract persistent identifiers such as a UUID or similar. These 167 IDs, which e.g. identify the installation of a certain application 168 might not change across updates of the software and are therefore 169 extremely long lived. This allows a passive observer to track a user 170 precisely if broadcast/multicast messages are frequent. This is even 171 true in case the IP and/or MAC address changes. Such identifiers 172 also allow two different interfaces (e.g. WiFi and Ethernet) to be 173 correlated to the same device. If the application makes use of 174 persistent identifiers for multiple installations of the same 175 application for the same user, this even allows to infer that 176 different devices belong to the same user. 178 If a broadcast/multicast protocol relies on IDs to be transmitted, it 179 SHOULD be considered if frequent ID rotations are possible in order 180 to make user tracking more difficult. Persistent IDs are considered 181 bad practice in general for broadcast and multicast communication as 182 persistent application layer IDs will make efforts on lower layers to 183 randomize identifiers (e.g. [I-D.huitema-6man-random-addresses]) 184 useless or at least much more difficult. 186 2.3. Anticipate user behavior 188 A large number of users name their device after themselves, either 189 using their first name, last name or both. Often a hostname includes 190 the type, model or maker of a device, its function or includes 191 language specific information. Based on gathered data, this appears 192 currently to be prevalent user behavior [TRAC2016]. For protocols 193 using the hostname as part of the messages, this clearly will reveal 194 personally identifiable information to everyone on the local network. 195 This information can also be used to mount more sophisticated 196 attacks, when e.g. the owner of a device is identified (as an 197 interesting target) or properties of the device are known (e.g. known 198 vulnerabilities). 200 Where possible, the use of hostnames and other user provided 201 information in broadcast/multicast protocols SHOULD be avoided. If 202 only a persistent ID is needed, this can be generated. An 203 application might want to display the information it will broadcast 204 on the LAN at install/config time, so the user is at least aware of 205 the application's behavior. More hostname considerations can be 206 found in [I-D.ietf-intarea-hostname-practice]. More information on 207 user participation can be found in [RFC6973]. 209 2.4. Consider potential correlation 211 A large number of services and applications make use of the 212 broadcast/multicast mechanism. That means there are various sources 213 of information that are easily accessible by a passive observer. In 214 isolation, the information these protocols reveal might seem 215 harmless, but given multiple such protocols, it might be possible to 216 correlate this information. E.g. a protocol that uses frequent 217 messages including a UUID to identify the particular installation 218 does not give the identity of the user away. But a single message 219 including the user's hostname might just do that and it can be 220 correlated using e.g. the MAC address of the device's interface. 222 A broadcast protocol designer should be aware of the fact that even 223 if - in isolation - the information a protocol leaks seems harmless, 224 there might be ways to correlate that information with other 225 broadcast protocol information to reveal sensitive information about 226 a user. 228 2.5. Configurability 230 A lot of applications and services using broadcast/multicast 231 protocols do not include the means to declare "safe" environments 232 (e.g. based on the SSID of a WiFi network and MAC addresses of access 233 points). E.g. a device connected to a public WiFi will likely 234 broadcast the same information as when connected to the home network. 235 It would be beneficial if certain behavior could be restricted to 236 "safe" environments. 238 An application developer making use of broadcasts/multicasts as part 239 of the application SHOULD make the broadcast feature, if possible, 240 configurable, so that potentially sensitive information does not leak 241 on public networks, where the thread to privacy is much larger. 243 3. Operational considerations 245 Besides changing end-user behavior, choosing sensible defaults as an 246 operating system vendor (e.g. for suggesting host names) and the 247 considerations for protocol designers mentioned in this document, 248 there are things that the network administrators/operators can do to 249 limit the above mentioned problems. 251 A feature not uncommonly found on access points e.g. is to filter 252 broadcast and multicast traffic. This will potentially break certain 253 applications or some of their functionality but will also protect the 254 users from potentially leaking sensitive information. 256 4. Summary 258 Increasingly, applications rely on broadcast and multicast messages. 259 For some, broadcasts/multicasts are the basis of their application 260 logic, others use broadcasts to improve certain aspects of the 261 application but are fully functional in case broadcasts fail. 262 Irrespective of the role of broadcast and multicast messages for the 263 application, the designers of protocols that make use of them should 264 be very careful in their protocol design because of the special 265 nature of broad- and multicast. 267 It is not always possible to implememt certain functionality via 268 unicast, but in case a protocol designer chooses to rely on 269 broadcast/multicast, the following should be carefully considered: 271 o IETF-specified protocols, such as mDNS [RFC6762], should be used 272 if possible as operational support might exist to protect against 273 the leakage of private information 275 o Avoid using user-specified information inside broadcast/multicast 276 messages as users will often use personal information or other 277 information aiding attackers, in particular if the user is unaware 278 about how that information is being used 280 o Avoid persistent IDs in messages as this allows user tracking, 281 correlation and potentially has a devastating effect on other 282 privacy protection mechanisms 284 o If you really must use a broadcast/multicast protocol and cannot 285 use an IETF-specified protocol, then: 287 * Be very conservative in how frequently you send messages as an 288 effort in data minimization 290 * Seek advice from IETF-specifies protocols such as message 291 suppression in mDNS 293 * Try to design the protocol in a way that the information cannot 294 be correlated with other information in broadcast/multicast 295 messages 297 * Let the user configure safe environments if possible (e.g. 298 based on the SSID) 300 [Note: discussions on this document should be take place on the 301 Intarea mailing list of the IETF. Subscription: 302 https://www.ietf.org/mailman/listinfo/int-area, Mailing list archive: 303 https://www.ietf.org/mail-archive/web/int-area/current/maillist.html] 305 5. Other considerations 307 Besides the privacy implications of frequent broadcasting, it also 308 represents a performance problem. In particular in certain wireless 309 technologies such as 802.11, broadcast and multicast are transmitted 310 at a much lower rate (the lowest common denominator rate) compared to 311 unicast and therefore have a much bigger impact on the overall 312 available airtime. Further, it will limit the ability for devices to 313 go to sleep if frequent broadcasts are being sent. A similar problem 314 in respect to Router Advertisements is addressed in 315 [I-D.ietf-v6ops-reducing-ra-energy-consumption]. In that respect 316 broadcasts can be used for another class of attacks that not related 317 to privacy. The potential impact on network performance should 318 nevertheless be considered by broadcast protocol designers. 320 6. Acknowledgments 322 We would like to thank Eliot Lear and Stephane Bortzmeyer for their 323 input. 325 This work was partly supported by the European Commission under grant 326 agreement FP7-318627 mPlane. Support does not imply endorsement. 328 7. IANA Considerations 330 This memo includes no request to IANA. 332 8. Security Considerations 334 This document deals with privacy-related considerations of broadcast- 335 and multicast-based protocols. It contains advice for designers of 336 such protocols to minimize the leakage of privacy-sensitive 337 information. The intent of the advice is to make sure that 338 identities will remain anonymous and user tracking will be made 339 difficult. 341 9. Informative References 343 [I-D.huitema-6man-random-addresses] 344 Huitema, C., "Implications of Randomized Link Layers 345 Addresses for IPv6 Address Assignment", draft-huitema- 346 6man-random-addresses-03 (work in progress), March 2016. 348 [I-D.ietf-intarea-hostname-practice] 349 Huitema, C. and D. Thaler, "Current Hostname Practice 350 Considered Harmful", draft-ietf-intarea-hostname- 351 practice-00 (work in progress), October 2015. 353 [I-D.ietf-v6ops-reducing-ra-energy-consumption] 354 Yourtchenko, A. and L. Colitti, "Reducing energy 355 consumption of Router Advertisements", draft-ietf-v6ops- 356 reducing-ra-energy-consumption-03 (work in progress), 357 November 2015. 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, March 1997. 362 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 363 Extensions for Stateless Address Autoconfiguration in 364 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 365 . 367 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 368 DOI 10.17487/RFC6762, February 2013, 369 . 371 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 372 Morris, J., Hansen, M., and R. Smith, "Privacy 373 Considerations for Internet Protocols", RFC 6973, DOI 374 10.17487/RFC6973, July 2013, 375 . 377 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 378 Considerations for IPv6 Address Generation Mechanisms", 379 RFC 7721, DOI 10.17487/RFC7721, March 2016, 380 . 382 [RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy 383 Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, 384 April 2016, . 386 [TRAC2016] 387 Faath, M., Weisshaar, F., and R. Winter, "How Broadcast 388 Data Reveals Your Identity and Social Graph", 7th 389 International Workshop on TRaffic Analysis and 390 Characterization IEEE TRAC 2016, September 2016. 392 Authors' Addresses 394 Rolf Winter 395 University of Applied Sciences Augsburg 396 Augsburg 397 DE 399 Email: rolf.winter@hs-augsburg.de 401 Michael Faath 402 University of Applied Sciences Augsburg 403 Augsburg 404 DE 406 Email: michael.faath@hs-augsburg.de 408 Fabian Weisshaar 409 University of Applied Sciences Augsburg 410 Augsburg 411 DE 413 Email: fabian.weisshaar@hs-augsburg.de