Internet Engineering Task Force (IETF) R. Winter
Request for Comments: 8386 University of Applied Sciences Augsburg
Category: Informational M. Faath
ISSN: 2070-1721 Conntac GmbH
F. Weisshaar
University of Applied Sciences Augsburg
May 2018
Internet Engineering Task Force (IETF) R. Winter
Request for Comments: 8386 University of Applied Sciences Augsburg
Category: Informational M. Faath
ISSN: 2070-1721 Conntac GmbH
F. Weisshaar
University of Applied Sciences Augsburg
May 2018
Privacy Considerations for Protocols Relying on IP Broadcast or Multicast
依赖IP广播或多播的协议的隐私注意事项
Abstract
摘要
A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content. Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols.
许多应用层协议利用IP广播或多播消息实现本地服务发现或名称解析等功能。其中一些功能只能使用此类机制有效地实现。当使用广播或多播消息时，同一广播或多播域中的被动观察者可以轻松地记录这些消息并分析其内容。因此，使用广播或多播消息的协议的设计者在设计其协议时需要特别小心。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8386.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
Broadcast and multicast messages have a large (and, to the sender, unknown) receiver group by design. Because of that, these two mechanisms are vital for a number of basic network functions such as autoconfiguration and link-layer address lookup. Also, application developers use broadcast/multicast messages to implement things such as local service or peer discovery. It appears that an increasing number of applications make use of it as suggested by experimental results obtained on campus networks, including the IETF meeting network [TRAC2016]. This trend is not entirely surprising. As
广播和多播消息在设计上有一个较大的（对于发送方来说，未知的）接收方组。因此，这两种机制对于一些基本的网络功能至关重要，如自动配置和链路层地址查找。此外，应用程序开发人员使用广播/多播消息来实现本地服务或对等发现等功能。正如在校园网络（包括IETF会议网络）上获得的实验结果所表明的那样，越来越多的应用程序使用它[TRAC2016]。这一趋势并不完全令人惊讶。像
[RFC919] puts it, "The use of broadcasts [...] is a good base for many applications". Broadcast and multicast functionality in a subnetwork is therefore important because a lack thereof renders the protocols relying on these mechanisms inoperable [RFC3819].
[RFC919]指出，“广播的使用[…]是许多应用的良好基础”。因此，子网中的广播和多播功能非常重要，因为缺少广播和多播功能会导致依赖这些机制的协议无法运行[RFC3819]。
Using broadcast/multicast can become problematic if the information that is being distributed can be regarded as sensitive or if the information that is distributed by multiple protocols can be correlated in a way that sensitive data can be derived. This is clearly true for any protocol, but broadcast/multicast is special in at least two respects:
如果正在分发的信息可以被视为敏感信息，或者如果通过多个协议分发的信息可以以导出敏感数据的方式进行关联，则使用广播/多播可能会出现问题。这显然适用于任何协议，但广播/多播至少在两个方面是特殊的：
(a) The aforementioned large receiver group consists of receivers unknown to the sender. This makes eavesdropping without special privileges or a special location in the network trivial for anybody in the same broadcast/multicast domain.
(a) 上述大型接收器组由发送方未知的接收器组成。这使得在网络中没有特殊权限或特殊位置的窃听对于同一广播/多播域中的任何人来说都是微不足道的。
(b) Encryption is difficult when broadcast/multicast messages are used, because, for instance, a non-trivial key management protocol might be required. When encryption is not used, the content of these messages is easily accessible, making it easy to spoof and replay them.
(b) 当使用广播/多播消息时，加密是困难的，因为，例如，可能需要一个非平凡的密钥管理协议。当不使用加密时，这些消息的内容很容易访问，从而很容易欺骗和重播它们。
Given the above, privacy protection for protocols based on broadcast or multicast communication is significantly more difficult compared to unicast communication, and at the same time, invasion of privacy is much easier.
综上所述，与单播通信相比，基于广播或多播通信的协议的隐私保护要困难得多，同时，隐私入侵也要容易得多。
Privacy considerations for IETF-specified protocols have received some attention in the recent past (e.g., [RFC7721] and [RFC7819]). There is also general guidance available for document authors on when and how to include a privacy considerations section in their documents and on how to evaluate the privacy implications of Internet protocols [RFC6973]. RFC 6973 also describes potential threats to privacy in great detail and lists terminology that is also used in this document. In contrast to RFC 6973, this document contains a number of privacy considerations, especially for protocols that rely on broadcast/multicast, that are intended to reduce the likelihood that a broadcast- or multicast-based protocol can be misused to collect sensitive data about devices, users, and groups of users in a broadcast/multicast domain.
Privacy considerations for IETF-specified protocols have received some attention in the recent past (e.g., [RFC7721] and [RFC7819]). There is also general guidance available for document authors on when and how to include a privacy considerations section in their documents and on how to evaluate the privacy implications of Internet protocols [RFC6973]. RFC 6973 also describes potential threats to privacy in great detail and lists terminology that is also used in this document. In contrast to RFC 6973, this document contains a number of privacy considerations, especially for protocols that rely on broadcast/multicast, that are intended to reduce the likelihood that a broadcast- or multicast-based protocol can be misused to collect sensitive data about devices, users, and groups of users in a broadcast/multicast domain.translate error, please retry
The above-mentioned considerations particularly apply to protocols designed outside the IETF for two reasons. First, non-standard protocols will likely not receive operational attention and support in making them more secure, e.g., what DHCP snooping does for DHCP. Because these protocols are typically not documented, network equipment does not provide similar features for them. Second, these
出于两个原因，上述考虑尤其适用于在IETF之外设计的协议。首先，非标准协议可能不会得到操作上的关注和支持，以使它们更安全，例如DHCP窥探对DHCP的作用。因为这些协议通常没有文档记录，所以网络设备没有为它们提供类似的功能。第二，这些
protocols have been designed in isolation, where a set of considerations to follow is useful in the absence of a larger community providing feedback and expertise to improve the protocol. In particular, carelessly designed protocols that use broadcast/ multicast can break privacy efforts at different layers of the protocol stack such as Media Access Control (MAC) address or IP address randomization [RFC4941].
协议是单独设计的，在没有更大的社区提供反馈和专业知识来改进协议的情况下，遵循一组考虑是有用的。特别是，不小心设计的使用广播/多播的协议可能会破坏协议栈不同层的隐私保护，例如媒体访问控制（MAC）地址或IP地址随机化[RFC4941]。
In IPv4, two major types of broadcast addresses exist: 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 and the local part of all-ones. Broadcast packets are received by all nodes in a subnetwork. Limited broadcasts never transit a router. The same is true for directed broadcasts by default, but routers may provide an option to do this [RFC2644]. IPv6, on the other hand, does not provide broadcast addresses but relies solely on multicast [RFC4291].
在IPv4中，存在两种主要类型的广播地址：有限广播和定向广播。[RFC1812]第5.3.5节将有限广播定义为所有广播（255.255.255.255），并将定向广播定义为IP地址的给定网络前缀和所有广播的本地部分。广播数据包由子网中的所有节点接收。有限的广播从不通过路由器。默认情况下，定向广播也是如此，但是路由器可以提供一个选项来实现这一点[RFC2644]。另一方面，IPv6不提供广播地址，但仅依赖于多播[RFC4291]。
In contrast to broadcast addresses, multicast addresses represent an identifier for a set of interfaces that can be a set different from all nodes in the subnetwork. All interfaces that are identified by a given multicast address receive packets destined towards that address and are called a "multicast group". In both IPv4 and IPv6, multiple pre-defined multicast addresses exist. The ones most relevant 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]).
与广播地址不同，多播地址表示一组接口的标识符，这些接口可以是与子网中所有节点不同的一组。由给定多播地址标识的所有接口都接收指向该地址的数据包，称为“多播组”。在IPv4和IPv6中，都存在多个预定义的多播地址。与本文档最相关的是具有子网范围的。对于IPv4，为此保留了一个称为“本地网络控制块”（224.0.0.0/24，定义见[RFC5771]第4节）的IP前缀。对于IPv6，相关的多播地址是两个全节点地址，每个支持IPv6的主机都需要将其识别为标识自身（请参见[RFC4291]第2.7.1节）。
Typical usage of these addresses includes local service discovery (e.g., Multicast DNS (mDNS) [RFC6762] and Link-Local Multicast Name Resolution (LLMNR) [RFC4795] make use of multicast), autoconfiguration (e.g., DHCPv4 [RFC2131] uses broadcasts, and DHCPv6 [RFC3315] uses multicast addresses), and other vital network services such as address resolution or duplicate address detection. Aside from these core network functions, applications also make use of broadcast and multicast functionality, often implementing proprietary protocols. In sum, these protocols distribute a diverse set of potentially privacy-sensitive information to a large receiver group, and the only requirement to be part of this receiver group is to be on the same subnetwork.
这些地址的典型用法包括本地服务发现（例如，多播DNS（MDN）[RFC6762]和链路本地多播名称解析（LLMNR）[RFC4795]使用多播）、自动配置（例如，DHCPv4[RFC2131]使用广播，DHCPv6[RFC3315]使用多播地址），以及其他重要的网络服务，如地址解析或重复地址检测。除了这些核心网络功能外，应用程序还利用广播和多播功能，通常实现专有协议。总之，这些协议将一组不同的可能对隐私敏感的信息分发给一个较大的接收方组，并且成为该接收方组一部分的唯一要求是位于同一子网上。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
There are a few obvious and a few not necessarily obvious things that designers of protocols utilizing broadcast/multicast should consider in respect to the privacy implications for their protocol. Most of these items are based on protocol behavior observed as part of experiments on operational networks [TRAC2016].
使用广播/多播协议的设计者在考虑其协议的隐私影响时，有一些明显的和不一定是显而易见的事情。这些项目中的大多数都基于在操作网络上进行的实验中观察到的协议行为[TRAC2016]。
Frequent broadcast/multicast traffic caused by an application can give away user behavior and online connection times. This allows a passive observer to potentially deduce a user's current activity (e.g., a game) and to create an online profile (i.e., times the user is on the network). This profile becomes more accurate as the frequency of messages and the time duration over which they are sent increases. Given that broadcast/multicast messages are only visible in the same broadcast/multicast domain, these messages also give away the rough location of the user (e.g., a campus or building).
由应用程序引起的频繁广播/多播流量会泄露用户行为和在线连接时间。这允许被动观察者推断用户当前的活动（例如，游戏）并创建在线配置文件（例如，用户在网络上的时间）。随着消息频率和发送时间的增加，此配置文件变得更加准确。鉴于广播/多播消息仅在同一广播/多播域中可见，这些消息还提供了用户的大致位置（例如，校园或建筑物）。
This behavior has, for example, been observed by a synchronization mechanism of a popular application, where multiple messages have been sent per minute via broadcast. Given this behavior, it is possible to record a device's time on the network with a sub-minute accuracy given only the traffic of this single application installed on the device. Also, services used for local name resolution in modern operating systems utilize broadcast- or multicast-based protocols (e.g., mDNS, LLMNR, or NetBIOS) to announce, for example, resources on a regular basis. This also allows tracking of the online times of a device.
例如，流行应用程序的同步机制观察到了这种行为，其中每分钟通过广播发送多条消息。考虑到这种行为，仅考虑设备上安装的单个应用程序的流量，就可以以亚分钟的精度记录设备在网络上的时间。此外，现代操作系统中用于本地名称解析的服务利用基于广播或多播的协议（例如，MDN、LLMNR或NetBIOS）定期宣布资源。这还允许跟踪设备的在线时间。
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 such as the ones employed in mDNS [RFC6762] SHOULD be implemented. The lower the frequency of broadcast messages, the harder passive traffic analysis and surveillance becomes.
如果协议依赖于频繁或定期广播/多播消息，则应保守选择频率，特别是如果消息包含持久标识符（见第2.2节）。此外，还应实现智能消息抑制机制，如MDN[RFC6762]中采用的机制。广播消息的频率越低，被动流量分析和监视就越困难。
A few protocols that make use of broadcast/multicast messages observed in the wild also make use of persistent identifiers. This includes the use of host names or more abstract persistent identifiers such as a Universally Unique Identifiers (UUIDs) or similar. These IDs, which, for example, identify the installation of a certain application, might not change across updates of the software and can therefore be extremely long lived. This allows a passive observer to track a user precisely if broadcast/multicast messages are frequent. This is even true if the IP and/or MAC address changes. Such identifiers also allow two different interfaces (e.g., Wi-Fi and Ethernet) to be correlated to the same device. If the application makes use of persistent identifiers for multiple installations of the same application for the same user, this even allows a passive observer to infer that different devices belong to the same user.
一些利用在野外观察到的广播/多播消息的协议也利用持久标识符。这包括使用主机名或更抽象的持久标识符，如通用唯一标识符（UUID）或类似标识符。这些ID（例如，标识特定应用程序的安装）可能不会随着软件的更新而改变，因此可能非常长寿。这允许被动观察者在广播/多播消息频繁时精确跟踪用户。即使IP和/或MAC地址发生变化，情况也是如此。此类标识符还允许将两个不同的接口（例如Wi-Fi和以太网）关联到同一设备。如果应用程序对同一用户的同一应用程序的多个安装使用持久标识符，这甚至允许被动观察者推断不同的设备属于同一用户。
The aforementioned broadcast messages from a synchronization mechanism of a popular application also included a persistent identifier in every broadcast. This identifier never changed after the application was installed, which allowed for the tracking of a device even when it changed its network interface or when it connected to a different network.
来自流行应用的同步机制的前述广播消息还包括每个广播中的持久标识符。此标识符在安装应用程序后从未更改，这允许跟踪设备，即使设备更改了其网络接口或连接到其他网络时也是如此。
In general, persistent IDs are considered bad practice for broadcast and multicast communication, as persistent application-layer IDs will make efforts to randomize identifiers (e.g., [RANDOM-ADDR]) on lower layers useless. When protocols that make use of broadcast/multicast need to make use of IDs, these IDs SHOULD be rotated frequently to make user tracking more difficult.
通常，持久化ID被认为是广播和多播通信的坏做法，因为持久化应用层ID将使下层上的标识符（例如，[RANDOM-ADDR]）随机化是无用的。当使用广播/多播的协议需要使用ID时，这些ID应该频繁轮换，以使用户跟踪更加困难。
A large number of users name their device after themselves, either using their first name, last name, or both. Often, a host name includes the type, model, or maker of a device, its function, or language-specific information. Based on data gathered during experiments performed at IETF meetings and at a large campus network, this appears to be the currently prevalent user behavior [TRAC2016]. For protocols using the host name as part of the messages, this clearly will reveal personally identifiable information to everyone on the local network. This information can also be used to mount more sophisticated attacks, e.g., when the owner of a device is identified (as an interesting target) or properties of the device are known (e.g., known vulnerabilities). Host names are also a type of persistent identifier; therefore, the considerations in Section 2.2 apply.
大量用户以自己的名字命名他们的设备，或者使用他们的名字、姓氏，或者两者都使用。主机名通常包括设备的类型、型号或制造商、功能或特定于语言的信息。根据在IETF会议和大型校园网络上进行的实验中收集的数据，这似乎是当前流行的用户行为[TRAC2016]。对于使用主机名作为消息一部分的协议，这将清楚地向本地网络上的每个人显示个人身份信息。此信息还可用于发起更复杂的攻击，例如，当设备的所有者被识别（作为感兴趣的目标）或设备的属性已知（例如，已知漏洞）时。主机名也是一种持久标识符；因此，第2.2节中的注意事项适用。
Some of the most commonly used operating systems include the name the user chooses for the user account during the installation process as part of the host name of the device. The name of the operating system can also be included, therefore revealing two pieces of information that can be regarded as private information if the host name is used in broadcast/multicast messages.
一些最常用的操作系统包括用户在安装过程中为用户帐户选择的名称，作为设备主机名的一部分。还可以包括操作系统的名称，因此，如果在广播/多播消息中使用主机名，则会显示两条可被视为私有信息的信息。
Where possible, the use of host names and other user-provided information in protocols making use of broadcast/multicast SHOULD be avoided. An application might want to display the information it will broadcast on the LAN at install/config time, so that the user is at least aware of the application's behavior. More host name considerations can be found in [RFC8117]. More information on user participation can be found in [RFC6973].
在可能的情况下，应避免在使用广播/多播的协议中使用主机名和其他用户提供的信息。应用程序可能希望在安装/配置时显示它将在LAN上广播的信息，以便用户至少知道应用程序的行为。更多主机名注意事项可在[RFC8117]中找到。有关用户参与的更多信息，请参见[RFC6973]。
A large number of services and applications make use of the broadcast/multicast mechanism. That means there are various sources of information that are easily accessible by a passive observer. In isolation, the information these protocols reveal might seem harmless, but given multiple such protocols, it might be possible to correlate this information. For example, a protocol that uses frequent messages including a UUID to identify the particular installation does not give away the identity of the user. However, a single message including the user's host name might do that, and it can be correlated using, for example, the MAC address of the device's interface.
大量服务和应用程序使用广播/多播机制。这意味着被动观察者很容易获得各种信息源。孤立地说，这些协议所揭示的信息可能看起来是无害的，但是如果有多个这样的协议，就有可能将这些信息关联起来。例如，使用频繁消息（包括UUID）来标识特定安装的协议不会泄露用户身份。但是，包含用户主机名的单个消息可能会做到这一点，并且可以使用设备接口的MAC地址等将其关联起来。
In the experiments described in [TRAC2016], it was possible to correlate frequently sent broadcast messages that included a unique identifier with other broadcast/multicast messages containing usernames (e.g. mDNS, LLMNR, or NetBIOS); this revealed relationships among users. This allowed the real identity of the users of many devices to be revealed, and it also gave away some information about their social environment.
在[TRAC2016]中描述的实验中，可以将频繁发送的包含唯一标识符的广播消息与包含用户名的其他广播/多播消息（例如MDN、LLMNR或NetBIOS）关联起来；这揭示了用户之间的关系。这使得许多设备用户的真实身份得以披露，同时也泄露了他们社交环境的一些信息。
A designer of a protocol that makes use of broadcast/multicast needs to be aware of the fact that even if the information a protocol leaks seems harmless in isolation, there might be ways to correlate that information with information from other protocols to reveal sensitive information about a user.
使用广播/多播的协议的设计者需要意识到这样一个事实，即即使协议泄漏的信息单独看来是无害的，也可能有方法将该信息与来自其他协议的信息关联起来，以揭示关于用户的敏感信息。
A lot of applications and services relying on broadcast- or multicast-based protocols do not include the means to declare "safe" environments (e.g., based on the Service Set Identifier (SSID) of a
许多依赖基于广播或多播协议的应用程序和服务不包括声明“安全”环境的方法（例如，基于服务的服务集标识符（SSID））
Wi-Fi network and the MAC addresses of the access points). For example, a device connected to a public Wi-Fi network will likely broadcast the same information as when connected to the home network. It would be beneficial if certain behaviors could be restricted to "safe" environments.
Wi-Fi网络和接入点的MAC地址）。例如，连接到公共Wi-Fi网络的设备可能会广播与连接到家庭网络时相同的信息。如果某些行为可以限制在“安全”的环境中，这将是有益的。
For example, a popular operating system allows the user to specify the trust level of the network the device connects to, which, for example, restricts specific system services (using broadcast/ multicast messages for their normal operation) to be used in trusted networks only. Such functionality could be implemented as part of an application.
例如，流行的操作系统允许用户指定设备连接到的网络的信任级别，例如，该级别限制特定系统服务（使用广播/多播消息进行正常操作）仅在受信任网络中使用。这种功能可以作为应用程序的一部分实现。
An application developer making use of broadcast/multicast messages as part of the application SHOULD, if possible, make the broadcast feature configurable so that potentially sensitive information does not leak on public networks where the threat to privacy is much larger.
如果可能，将广播/多播消息作为应用程序的一部分使用的应用程序开发人员应使广播功能可配置，以便潜在的敏感信息不会在隐私威胁更大的公共网络上泄漏。
Besides changing end-user behavior, choosing sensible defaults as an operating system vendor (e.g., for suggesting host names), and following the considerations for protocol designers mentioned in this document, there is something that the network administrators/ operators can do to limit the above-mentioned problems.
除了更改最终用户行为、选择合理的默认值作为操作系统供应商（例如，建议主机名）以及遵循本文档中提到的协议设计者注意事项之外，网络管理员/运营商还可以采取一些措施来限制上述问题。
A feature commonly found on access points is the ability to manage/ filter broadcast and multicast traffic. This will potentially break certain applications or some of their functionality but will also protect the users from potentially leaking sensitive information. Wireless access points often provide finer-grained control beyond a simple on/off switch for well-known protocols or provide mechanisms to manage broadcast/multicast traffic intelligently using, for example, proxies (see [MCAST-CONS]). However, these mechanisms only work on standardized protocols.
接入点上常见的一个功能是管理/过滤广播和多播流量的能力。这可能会破坏某些应用程序或其某些功能，但也会保护用户免受潜在的敏感信息泄漏。无线接入点通常提供更细粒度的控制，而不仅仅是针对已知协议的简单开/关开关，或者提供使用代理（参见[MCAST-CONS]）等智能管理广播/多播流量的机制。然而，这些机制仅适用于标准化协议。
Increasingly, applications rely on protocols that send and receive broadcast and multicast messages. For some, broadcast/multicast messages are the basis of their application logic; others use broadcast/multicast messages to improve certain aspects of the application but are fully functional in case broadcast/multicast messages fail. Irrespective of the role of broadcast and multicast messages for the application, the designers of protocols that make use of them should be very careful in their protocol design because of the special nature of broadcast and multicast.
应用程序越来越依赖于发送和接收广播和多播消息的协议。对于一些人来说，广播/多播消息是其应用逻辑的基础；其他人使用广播/多播消息来改进应用程序的某些方面，但在广播/多播消息失败的情况下，这些消息将完全起作用。无论广播和多播消息在应用程序中扮演何种角色，由于广播和多播的特殊性质，使用它们的协议的设计者在协议设计时应非常小心。
It is not always possible to implement certain functionality via unicast, but if a protocol designer chooses to rely on broadcast/ multicast, the following should be carefully considered:
并非总是可以通过单播实现某些功能，但如果协议设计者选择依赖广播/多播，则应仔细考虑以下事项：
o IETF-specified protocols, such as mDNS [RFC6762], SHOULD be used if possible as operational support might exist to protect against the leakage of private information. Also, for some protocols, privacy extensions are being specified; these can be used if implemented. For example, for DNS-SD, privacy extensions are documented in [DNSSD-PRIV].
o 如果可能，应使用IETF指定的协议，如MDN[RFC6762]，因为可能存在操作支持，以防止私人信息泄漏。此外，对于某些协议，正在指定隐私扩展；如果实现了这些功能，就可以使用它们。例如，对于DNS-SD，隐私扩展记录在[DNSSD-PRIV]中。
o Using user-specified information inside broadcast/multicast messages SHOULD be avoided, as users will often use personal information or other information that aids attackers, in particular if the user is unaware about how that information is being used.
o 应避免在广播/多播消息中使用用户指定的信息，因为用户通常会使用个人信息或其他有助于攻击者的信息，特别是在用户不知道如何使用这些信息的情况下。
o The use of persistent IDs in messages SHOULD be avoided, as this allows user tracking and correlation, and it potentially has a devastating effect on other privacy-protection mechanisms.
o 应该避免在消息中使用持久ID，因为这允许用户跟踪和关联，并且可能会对其他隐私保护机制产生破坏性影响。
o If one must design a new protocol relying on broadcast/multicast and cannot use an IETF-specified protocol, then:
o 如果必须设计一个依赖广播/多播的新协议，并且不能使用IETF指定的协议，则：
* 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 be helpful in privacy protection, such as message suppression in mDNS,
* 它应该利用IETF指定协议中实现的机制，这些机制有助于隐私保护，例如MDN中的消息抑制，
* it SHOULD be designed in such a way that information sent in broadcast/multicast messages cannot be correlated with information 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 information leakage (e.g., a home network as opposed to a public Wi-Fi network).
* 如果可能，应允许用户配置“安全”环境（例如，基于SSID），以将信息泄漏风险降至最低（例如，家庭网络而非公共Wi-Fi网络）。
Besides privacy implications, frequent broadcasting also represents a performance problem. In particular, in certain wireless technologies such as 802.11, broadcast and multicast are transmitted at a much lower rate (the lowest common denominator rate) compared to unicast and therefore have a much bigger impact on the overall available airtime [MCAST-CONS]. Further, it will limit the ability for devices
除了隐私问题外，频繁广播也会带来性能问题。特别是，在某些无线技术（如802.11）中，广播和多播以比单播低得多的速率（最低公分母速率）传输，因此对总可用广播时间有更大的影响[MCAST-CONS]。此外，这将限制设备的功能
to go to sleep if frequent broadcasts are being sent. A similar problem in respect to Router Advertisements is addressed in [RFC7772]. In that respect, broadcast/multicast can be used for another class of attacks that is not related to privacy. The potential impact on network performance should nevertheless be considered when designing a protocol that makes use of broadcast/ multicast.
如果发送频繁的广播，就睡觉。[RFC7772]中解决了与路由器广告相关的类似问题。在这方面，广播/多播可用于与隐私无关的另一类攻击。然而，在设计使用广播/多播的协议时，应考虑对网络性能的潜在影响。
This document has no IANA actions.
本文档没有IANA操作。
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 intent of the advice is to make sure that identities will remain anonymous and 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.
为了保护多播流量，某些应用程序可以利用现有机制，如[RFC5374]中定义的机制。此类应用的示例见[RFC5374]的附录A。然而，考虑到对这些应用程序和所需安全基础设施的假设，许多应用程序将无法使用这些机制。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[DNSSD-PRIV] Huitema, C. and D. Kaiser, "Privacy Extensions for DNS-SD", Work in Progress, draft-ietf-dnssd-privacy-04, April 2018.
[DNSSD-PRIV]Huitema，C.和D.Kaiser，“DNS-SD的隐私扩展”，正在进行中的工作，草稿-ietf-DNSSD-Privacy-042018年4月。
[MCAST-CONS] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", Work in Progress, draft-ietf-mboned-ieee802-mcast-problems-01, February 2018.
[MCAST-CONS]Perkins，C.，McBride，M.，Stanley，D.，Kumari，W.，和J.Zuniga，“IEEE 802无线媒体上的多播注意事项”，正在进行的工作，草案-ietf-mboned-ieee802-MCAST-problems-012018年2月。
[RANDOM-ADDR] Huitema, C., "Implications of Randomized Link Layers Addresses for IPv6 Address Assignment", Work in Progress, draft-huitema-6man-random-addresses-03, March 2016.
[RANDOM-ADDR]Huitema，C.，“随机链路层地址对IPv6地址分配的影响”，正在进行的工作，草稿-Huitema-6man-RANDOM-Addresses-032016年3月。
[RFC919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984, <https://www.rfc-editor.org/info/rfc919>.
[RFC919]Mogul，J.，“广播互联网数据报”，STD 5，RFC 919，DOI 10.17487/RFC0919，1984年10月<https://www.rfc-editor.org/info/rfc919>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/info/rfc1812>.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，DOI 10.17487/RFC1812，1995年6月<https://www.rfc-editor.org/info/rfc1812>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<https://www.rfc-editor.org/info/rfc2131>.
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, DOI 10.17487/RFC2644, August 1999, <https://www.rfc-editor.org/info/rfc2644>.
[RFC2644]Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 2644，DOI 10.17487/RFC2644，1999年8月<https://www.rfc-editor.org/info/rfc2644>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<https://www.rfc-editor.org/info/rfc3315>.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, DOI 10.17487/RFC3819, July 2004, <https://www.rfc-editor.org/info/rfc3819>.
[RFC3819]Karn，P.，Ed.，Bormann，C.，Fairhurst，G.，Grossman，D.，Ludwig，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，DOI 10.17487/RFC3819，2004年7月<https://www.rfc-editor.org/info/rfc3819>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<https://www.rfc-editor.org/info/rfc4291>.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, DOI 10.17487/RFC4795, January 2007, <https://www.rfc-editor.org/info/rfc4795>.
[RFC4795]Aboba，B.，Thaler，D.，和L.Esibov，“链路本地多播名称解析（LLMNR）”，RFC 4795，DOI 10.17487/RFC4795，2007年1月<https://www.rfc-editor.org/info/rfc4795>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<https://www.rfc-editor.org/info/rfc4941>.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, <https://www.rfc-editor.org/info/rfc5374>.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，DOI 10.17487/RFC5374，2008年11月<https://www.rfc-editor.org/info/rfc5374>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <https://www.rfc-editor.org/info/rfc5771>.
[RFC5771]Cotton，M.，Vegoda，L.，和D.Meyer，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 5771，DOI 10.17487/RFC5771，2010年3月<https://www.rfc-editor.org/info/rfc5771>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<https://www.rfc-editor.org/info/rfc6762>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<https://www.rfc-editor.org/info/rfc6973>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721]Cooper，A.，Gont，F.，和D.Thaler，“IPv6地址生成机制的安全和隐私考虑”，RFC 7721，DOI 10.17487/RFC7721，2016年3月<https://www.rfc-editor.org/info/rfc7721>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, <https://www.rfc-editor.org/info/rfc7772>.
[RFC7772]Yourtchenko，A.和L.Coletti，“降低路由器广告的能耗”，BCP 202，RFC 7772，DOI 10.17487/RFC7772，2016年2月<https://www.rfc-editor.org/info/rfc7772>.
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, April 2016, <https://www.rfc-editor.org/info/rfc7819>.
[RFC7819]Jiang，S.，Krishnan，S.，和T.Mrugalski，“DHCP的隐私考虑”，RFC 7819，DOI 10.17487/RFC78192016年4月<https://www.rfc-editor.org/info/rfc7819>.
[RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname Practice Considered Harmful", RFC 8117, DOI 10.17487/RFC8117, March 2017, <https://www.rfc-editor.org/info/rfc8117>.
[RFC8117]Huitema，C.，Thaler，D.，和R.Winter，“认为有害的当前主机名做法”，RFC 8117，DOI 10.17487/RFC81172017年3月<https://www.rfc-editor.org/info/rfc8117>.
[TRAC2016] Faath, M., Weisshaar, F., and R. Winter, "How Broadcast Data Reveals Your Identity and Social Graph", Wireless Communications and Mobile Computing Conference (IWCMC), International Workshop on TRaffic Analysis and Characterization (TRAC), DOI 10.1109/IWCMC.2016.7577084, September 2016.
[TRAC2016]Faath，M.，Weisshaar，F.，和R.Winter，“广播数据如何揭示您的身份和社交图”，无线通信和移动计算会议（IWCM），交通分析和特征国际研讨会（TRAC），DOI 10.1109/IWCM.2016.7577084，2016年9月。
Acknowledgments
致谢
We would like to thank Eliot Lear, Joe Touch, and Stephane Bortzmeyer for their valuable input to this document.
我们要感谢Eliot Lear、Joe Touch和Stephane Bortzmeyer对本文件的宝贵投入。
This work was partly supported by the European Commission under grant agreement FP7-318627 mPlane. Support does not imply endorsement.
根据FP7-318627 mPlane赠款协议，这项工作得到了欧盟委员会的部分支持。支持并不意味着认可。
Authors' Addresses
作者地址
Rolf Winter University of Applied Sciences Augsburg Augsburg Germany
罗尔夫国立奥格斯堡奥格斯堡应用科学大学
Email: rolf.winter@hs-augsburg.de
Email: rolf.winter@hs-augsburg.de
Michael Faath Conntac GmbH Augsburg Germany
Michael Faath Conntac GmbH德国奥格斯堡
Email: faath@conntac.net
Email: faath@conntac.net
Fabian Weisshaar University of Applied Sciences Augsburg Augsburg Germany
法比安-韦斯沙尔应用科学大学奥格斯堡奥格斯堡德国
Email: fabian.weisshaar@hs-augsburg.de
Email: fabian.weisshaar@hs-augsburg.de