RFC 8386

Privacy Considerations for Protocols Relying on IP Broadcast or Multicast

📅 published May 2018, from ietf

Privacy Considerations for Protocols Relying on IP Broadcast or Multicast 🦋

okay bestie, this is RFC 8386 💖 It's an Informational document from the IETF, which means it's guidance and not a Standards Track spec. It was published in May 2018 with ISSN 2070-1721. The authors are R. Winter and F. Weisshaar from the University of Applied Sciences Augsburg, plus M. Faath from Conntac GmbH. The title block doesn't list anything it obsoletes or updates, so it stands on its own 🌸

Abstract ✨

a bunch of application-layer protocols use IP broadcast or multicast messages for things like local service discovery or name resolution 🧚 some of those jobs can only be done efficiently with these mechanisms. the catch is that a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze what's inside 👀 so if you're designing a protocol that uses broadcast or multicast, you really need to take special care 💅

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8386.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. Types and Usage of Broadcast and Multicast .................4
   1.2. Requirements Language ......................................5
2. Privacy Considerations ..........................................5
   2.1. Message Frequency ..........................................5
   2.2. Persistent Identifiers .....................................6
   2.3. Anticipate User Behavior ...................................6
   2.4. Consider Potential Correlation .............................7
   2.5. Configurability ............................................7
3. Operational Considerations ......................................8
4. Summary .........................................................8
5. Other Considerations ............................................9
6. IANA Considerations ............................................10
7. Security Considerations ........................................10
8. References .....................................................10
   8.1. Normative References ......................................10
   8.2. Informative References ....................................10
Acknowledgments ...................................................13
Authors' Addresses ................................................13

1. Introduction 🌈

okay so broadcast and multicast messages have a big receiver group by design, and the sender doesn't actually know who's in it 😭 that's why these two mechanisms are vital for basic network stuff like autoconfiguration and link-layer address lookup. apps use them too, for things like local service or peer discovery. the vibe is that more and more applications are using them, and experimental results from campus networks, including the IETF meeting network, back that up [TRAC2016]. honestly not super surprising. as [RFC919] puts it, "The use of broadcasts [...] is a good base for many applications". so having broadcast and multicast working in a subnetwork is a big deal, because without it, the protocols that depend on them just don't work [RFC3819] 💖

using broadcast or multicast gets messy when the stuff being distributed is sensitive, or when info from several protocols can be combined to reveal something private 🙈 this is true for any protocol, but broadcast and multicast are special in at least two ways:

  • (a) that big receiver group is made of receivers the sender doesn't know. so eavesdropping is trivial for anyone in the same broadcast or multicast domain, no special privileges or special network location needed 👀
  • (b) encryption is hard with broadcast and multicast, because, for example, you might need a non-trivial key management protocol. and when encryption isn't used, the content is easy to get at, which makes it easy to spoof and replay messages 💀

so yeah, protecting privacy for broadcast or multicast protocols is way harder than for unicast, and at the same time, invading privacy is way easier 😤

privacy considerations for IETF protocols have gotten some attention lately (for example [RFC7721] and [RFC7819]) 🧚 there's also general guidance for document authors on when and how to include a privacy considerations section, and on how to evaluate the privacy implications of Internet protocols [RFC6973]. RFC 6973 also goes deep on potential privacy threats and lists terminology that this document uses too. the difference is that this document has a bunch of privacy considerations specifically for protocols that rely on broadcast or multicast. the goal is to make it less likely that a broadcast- or multicast-based protocol gets misused to collect sensitive data about devices, users, and groups of users in a broadcast or multicast domain 🎀

the above especially applies to protocols designed outside the IETF, and there are two reasons for that 🍓 first, non-standard protocols probably won't get operational attention and support for making them more secure, like what DHCP snooping does for DHCP. and because these protocols usually aren't documented, network equipment doesn't offer similar features for them. second, these protocols were designed in isolation, so a set of things to consider is useful when there's no bigger community giving feedback and expertise to improve the protocol. in particular, carelessly designed protocols that use broadcast or multicast can break privacy efforts at different layers of the protocol stack, like Media Access Control (MAC) address or IP address randomization [RFC4941] 😭💅

1.1. Types and Usage of Broadcast and Multicast 🦋

in IPv4, there are two major types of broadcast addresses: limited broadcast and directed broadcast. Section 5.3.5 of [RFC1812] defines limited broadcast as all-ones (255.255.255.255), and defines directed broadcast as the given network prefix of an IP address with the local part set to all-ones. broadcast packets are received by all nodes in a subnetwork. limited broadcasts never transit a router. directed broadcasts don't either by default, but routers may provide an option to do this [RFC2644]. IPv6 is different, since it doesn't provide broadcast addresses at all and relies only on multicast [RFC4291] 🌸

multicast addresses are a different vibe. they're an identifier for a set of interfaces, and that set can be different from all nodes in the subnetwork. every interface identified by a given multicast address receives packets sent to that address, and that group is called a "multicast group" ✨ in both IPv4 and IPv6, there are several pre-defined multicast addresses. the ones that matter most for this document are the ones with subnet scope. for IPv4, an IP prefix called the "Local Network Control Block" (224.0.0.0/24, defined in Section 4 of [RFC5771]) is reserved for this purpose. for IPv6, the relevant multicast addresses are the two All Nodes Addresses, which every IPv6-capable host is required to recognize as identifying itself (see Section 2.7.1 of [RFC4291]) 🧚

these addresses show up in lots of places 💖 for local service discovery, there's Multicast DNS (mDNS) [RFC6762] and Link-Local Multicast Name Resolution (LLMNR) [RFC4795], which both use multicast. for autoconfiguration, DHCPv4 [RFC2131] uses broadcasts and DHCPv6 [RFC3315] uses multicast addresses. then there are other vital network services like address resolution and duplicate address detection. outside those core network functions, applications also use broadcast and multicast a lot, often with proprietary protocols 🙈 put it all together and these protocols spread a diverse set of potentially privacy-sensitive info to a large receiver group, and the only requirement to be in that group is being on the same subnetwork. no cap, that's the whole problem 😤

1.2. Requirements Language 📜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Privacy Considerations 🔒

there are a few obvious things, and a few not-so-obvious things, that designers of protocols using broadcast or multicast should think about when it comes to privacy implications for their protocol 👑 most of these items come from protocol behavior observed in experiments on operational networks [TRAC2016] ✨

2.1. Message Frequency ✨

okay so frequent broadcast/multicast traffic from an app can literally give away user behavior and online connection times 👀. A passive observer can potentially figure out what someone is doing right now (like, playing a game 🎮) and build an online profile, meaning the times the user is on the network. That profile gets more accurate as messages get sent more often and over longer stretches of time 📈. And since broadcast/multicast messages are only visible inside the same broadcast/multicast domain, they also reveal the rough location of the user, like a campus or a building 🏫. bestie this is so not it 💀

This has actually been spotted in the wild 🫣. A synchronization mechanism in a popular app sent multiple messages per minute via broadcast. From that one app's traffic alone, it's possible to record a device's time on the network with sub-minute accuracy 😭. Local name resolution services in modern operating systems also use broadcast- or multicast-based protocols (e.g., mDNS, LLMNR, or NetBIOS) to announce things like resources on a regular basis, so they can track a device's online times too 👀.

If a protocol relies on frequent or periodic broadcast/multicast messages, the frequency SHOULD be chosen conservatively, in particular if the messages contain persistent identifiers (see Section 2.2) 🎀. Also, intelligent message suppression mechanisms like the ones used in mDNS [RFC6762] SHOULD be implemented 🧠. The lower the frequency of broadcast messages, the harder passive traffic analysis and surveillance becomes 🦋.

2.2. Persistent Identifiers

okay now the ID drama 🥹. A few protocols that use broadcast/multicast messages in the wild also use persistent identifiers. That includes host names, or more abstract ones like Universally Unique Identifiers (UUIDs) or similar 🆔. These IDs, which can identify the installation of a certain app, might not change across updates, so they can be extremely long lived ⏳. That lets a passive observer track a user precisely if the broadcast/multicast messages are frequent. It's even true if the IP and/or MAC address changes 😵. Such identifiers also let two different interfaces (e.g., Wi-Fi and Ethernet) be correlated to the same device 🔗. And if the app uses persistent identifiers for multiple installations of the same application for the same user, a passive observer can infer that different devices belong to the same user 👯.

The broadcast messages from that synchronization mechanism I mentioned also included a persistent identifier in every broadcast. The ID never changed after the app was installed, so the device could be tracked even when it changed its network interface or connected to a different network 💀.

In general, persistent IDs are considered bad practice for broadcast and multicast communication, because persistent application-layer IDs will make efforts to randomize identifiers (e.g., [RANDOM-ADDR]) on lower layers useless 🙅‍♀️. When protocols that use broadcast/multicast need IDs, these IDs SHOULD be rotated frequently to make user tracking more difficult 🔄💜.

2.3. Anticipate User Behavior

real talk, a huge number of users name their device after themselves, using their first name, last name, or both 🙈. A host name often includes the type, model, or maker of the device, its function, or language-specific info too 💻. Based on data gathered during experiments at IETF meetings and at a large campus network, this looks like the most common user behavior right now [TRAC2016] 📊. For protocols that put the host name in their messages, this will clearly reveal personally identifiable information to everyone on the local network 😱. It can also be used for more sophisticated attacks, like when the owner of a device gets identified as an interesting target, or when the properties of the device are known (e.g., known vulnerabilities) 🎯. Host names are also a type of persistent identifier, so the considerations in Section 2.2 apply 🔁.

Some of the most popular operating systems include the name the user picked for their user account during installation as part of the device's host name 🧑‍💻. The OS name can also be included, so that's two pieces of info that could count as private if the host name shows up in broadcast/multicast messages 🫠.

Where possible, the use of host names and other user-provided info in protocols that use broadcast/multicast SHOULD be avoided 🚫. An app might want to show the info it's going to broadcast on the LAN at install/config time, so the user is at least aware of what the app is doing 👀✨. More host name considerations can be found in [RFC8117]. More info on user participation can be found in [RFC6973] 📚.

2.4. Consider Potential Correlation

so many services and apps use the broadcast/multicast mechanism, which means there are lots of info sources a passive observer can easily access 🕵️‍♀️. On their own, the things these protocols reveal might seem harmless, but put several of them together and it might be possible to correlate them 🧩. For example, a protocol that sends frequent messages including a UUID to identify the installation doesn't give away the user's identity. But a single message including the user's host name might, and it can be correlated using, for example, the MAC address of the device's interface 😬.

In the experiments described in [TRAC2016], frequently sent broadcast messages that included a unique identifier could be correlated with other broadcast/multicast messages containing usernames (e.g., mDNS, LLMNR, or NetBIOS). That revealed relationships among users 🫨. It allowed the real identities of the users of many devices to be revealed, and it also gave away info about their social environment 💔.

If you're designing a protocol that uses broadcast/multicast, you need to know that even if the info a protocol leaks seems harmless alone, there might be ways to correlate it with info from other protocols to reveal sensitive info about a user 🚨. Stay aware, bestie 🫶.

2.5. Configurability

a lot of apps and services that rely on broadcast- or multicast-based protocols don't have a way to declare "safe" environments (e.g., based on the Service Set Identifier (SSID) of a Wi-Fi network and the MAC addresses of the access points) 🏠☕. For example, a device on a public Wi-Fi network will likely broadcast the same info as when it's on the home network 😳. It would be super beneficial if certain behaviors could be restricted to "safe" environments 💅.

A popular operating system lets the user set the trust level of the network the device connects to. That can, for example, restrict specific system services (which use broadcast/multicast messages for their normal operation) so they only run on trusted networks 🛡️. This kind of functionality could also be built into an app 🌸.

An app developer who uses broadcast/multicast messages as part of the app SHOULD, if possible, make the broadcast feature configurable, so potentially sensitive info doesn't leak on public networks where the privacy threat is much bigger 🔐🫧.

3. Operational Considerations

okay so besides changing end-user behavior, there are other ways to fix this. OS vendors can choose sensible defaults (like for suggested host names), protocol designers can follow the considerations in this document, and network administrators/operators can do something too to limit these problems 🧑‍🔧✨.

A feature commonly found on access points is the ability to manage/filter broadcast and multicast traffic 🚧. This can break certain apps or some of their functionality, but it also protects users from leaking sensitive info 🛡️. Wireless access points often offer finer-grained control beyond a simple on/off switch for well-known protocols, or they provide ways to manage broadcast/multicast traffic more intelligently, for example with proxies (see [MCAST-CONS]) 🧠. The catch is that these mechanisms only work on standardized protocols 😤.

4. Summary

okay the big takeaway 💖. More and more apps rely on protocols that send and receive broadcast and multicast messages 📲. For some, broadcast/multicast messages are the basis of the app logic. Others use them to improve certain parts of the app but stay fully functional if broadcast/multicast messages fail 🦋. No matter what role broadcast and multicast play in the app, designers of protocols that use them should be very careful in their protocol design, because broadcast and multicast are special 👑.

It's not always possible to do certain functionality over unicast, but if a protocol designer chooses to rely on broadcast/multicast, the following should be carefully considered 🧐:

  • IETF-specified protocols, such as mDNS [RFC6762], SHOULD be used if possible, because operational support might exist to protect against the leakage of private information 🛡️. Also, privacy extensions are being specified for some protocols, and these can be used if implemented. For example, for DNS-SD, privacy extensions are documented in [DNSSD-PRIV] 🌈.
  • Using user-specified info inside broadcast/multicast messages SHOULD be avoided, since users will often put in personal info or other info that helps attackers, especially if they don't know how that info is being used 🙈.
  • The use of persistent IDs in messages SHOULD be avoided, because it allows user tracking and correlation, and it can have a devastating effect on other privacy-protection mechanisms 💀.
  • If you must design a new protocol that relies on broadcast/multicast and can't use an IETF-specified protocol, then:
    • the protocol SHOULD be very conservative in how frequently it sends messages, as an effort in data minimization 🌸,
    • it SHOULD make use of mechanisms implemented in IETF-specified protocols that can help with privacy protection, such as message suppression in mDNS 🧚,
    • it SHOULD be designed so that info sent in broadcast/multicast messages can't be correlated with info from other protocols using broadcast/multicast, and 🔒
    • it SHOULD be possible to let the user configure "safe" environments if possible (e.g., based on the SSID) to minimize the risk of info leakage (e.g., a home network as opposed to a public Wi-Fi network) 🏡💜.

5. Other Considerations 💅

Okay bestie, privacy isn't the only thing that's sus about frequent broadcasting 🙈. It's also a performance problem! In certain wireless technologies like 802.11, broadcast and multicast get sent at a much lower rate (the lowest common denominator rate) compared to unicast. That means they eat way more of the overall available airtime [MCAST-CONS] 📉. It also limits how well devices can go to sleep if frequent broadcasts keep coming in 😴. A similar problem for Router Advertisements is handled in [RFC7772] 🌸. And in that respect, broadcast/multicast can be used for another class of attacks that has nothing to do with privacy 💀. The potential impact on network performance should nevertheless be considered when designing a protocol that makes use of broadcast/multicast 🫶.

6. IANA Considerations 🦋

This document has no IANA actions ✨.

7. Security Considerations 🔥

This one is serious, so let's get real for a sec 🫶. This document deals with privacy-related considerations for broadcast- and multicast-based protocols. It contains advice for designers of such protocols to minimize the leakage of privacy-sensitive information. The whole point of the advice is to make sure that identities will remain anonymous and that user tracking will be made difficult 🕵️‍♀️.

To protect multicast traffic, certain applications can make use of existing mechanisms, such as the ones defined in [RFC5374]. Examples of such applications can be found in Appendix A of [RFC5374] 📚. However, given the assumptions about these applications and the required security infrastructure, many applications will not be able to make use of such mechanisms 😭. Be careful out there, babe 🚨.

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgments 🫶

We would like to thank Eliot Lear, Joe Touch, and Stephane Bortzmeyer for their valuable input to this document 💖.

This work was partly supported by the European Commission under grant agreement FP7-318627 mPlane. Support does not imply endorsement 🌈.

Authors' Addresses 🎀

Rolf Winter
University of Applied Sciences Augsburg
Augsburg
Germany

Email: rolf.winter@hs-augsburg.de


Michael Faath
Conntac GmbH
Augsburg
Germany

Email: faath@conntac.net


Fabian Weisshaar
University of Applied Sciences Augsburg
Augsburg
Germany

Email: fabian.weisshaar@hs-augsburg.de
📦 where this page comes from