draft-ietf-intarea-broadcast-consider-05.txt   draft-ietf-intarea-broadcast-consider-06.txt 
Internet Engineering Task Force R. Winter Internet Engineering Task Force R. Winter
Internet-Draft University of Applied Sciences Augsburg Internet-Draft University of Applied Sciences Augsburg
Intended status: Informational M. Faath Intended status: Informational M. Faath
Expires: April 28, 2018 Conntac GmbH Expires: July 19, 2018 Conntac GmbH
F. Weisshaar F. Weisshaar
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
October 25, 2017 January 15, 2018
Privacy considerations for IP broadcast and multicast protocol designers Privacy considerations for protocols relying on IP broadcast and
draft-ietf-intarea-broadcast-consider-05 multicast
draft-ietf-intarea-broadcast-consider-06
Abstract Abstract
A number of application-layer protocols make use of IP broadcasts or A number of application-layer protocols make use of IP broadcasts or
multicast messages for functions like local service discovery or name multicast messages for functions like local service discovery or name
resolution. Some of these functions can only be implemented resolution. Some of these functions can only be implemented
efficiently using such mechanisms. When using broadcasts or efficiently using such mechanisms. When using broadcasts or
multicast messages, a passive observer in the same broadcast/ multicast messages, a passive observer in the same broadcast/
multicast domain can trivially record these messages and analyze multicast domain can trivially record these messages and analyze
their content. Therefore, broadcast/multicast protocol designers their content. Therefore, designers of protocols that make use
need to take special care when designing their protocols. broadcast/multicast messages need to take special care when designing
their protocols.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2018. This Internet-Draft will expire on July 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 30
2. Privacy considerations . . . . . . . . . . . . . . . . . . . 4 2. Privacy considerations . . . . . . . . . . . . . . . . . . . 4
2.1. Message frequency . . . . . . . . . . . . . . . . . . . . 5 2.1. Message frequency . . . . . . . . . . . . . . . . . . . . 5
2.2. Persistent identifiers . . . . . . . . . . . . . . . . . 5 2.2. Persistent identifiers . . . . . . . . . . . . . . . . . 5
2.3. Anticipate user behavior . . . . . . . . . . . . . . . . 6 2.3. Anticipate user behavior . . . . . . . . . . . . . . . . 6
2.4. Consider potential correlation . . . . . . . . . . . . . 7 2.4. Consider potential correlation . . . . . . . . . . . . . 7
2.5. Configurability . . . . . . . . . . . . . . . . . . . . . 7 2.5. Configurability . . . . . . . . . . . . . . . . . . . . . 7
3. Operational considerations . . . . . . . . . . . . . . . . . 8 3. Operational considerations . . . . . . . . . . . . . . . . . 8
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Other considerations . . . . . . . . . . . . . . . . . . . . 9 5. Other considerations . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Broadcast and multicast messages have a large (and to the sender Broadcast and multicast messages have a large (and to the sender
unknown) receiver group by design. Because of that, these two unknown) receiver group by design. Because of that, these two
mechanisms are vital for a number of basic network functions such as mechanisms are vital for a number of basic network functions such as
auto-configuration or link-layer address lookup. Also application auto-configuration or link-layer address lookup. Also application
developers use broadcast/multicast messages to implement things like developers use broadcast/multicast messages to implement things like
local service or peer discovery. It appears that an increasing local service or peer discovery. It appears that an increasing
number of applications make use of it as suggested by experimental number of applications make use of it as suggested by experimental
results obtained on campus networks including the IETF meeting results obtained on campus networks including the IETF meeting
network [TRAC2016]. This trend is not entirely surprising. As RFC network [TRAC2016]. This trend is not entirely surprising. As RFC
919 [RFC0919] puts it, "The use of broadcasts [...] is a good base 919 [RFC0919] puts it, "The use of broadcasts [...] is a good base
for many applications". Broadcast and multicast functionality in a for many applications". Broadcast and multicast functionality in a
subnetwork are therefore important as a lack thereof renders the subnetwork are therefore important as a lack thereof renders the
protocols underlying these mechanisms inoperable [RFC3819]. protocols relying on these mechanisms inoperable [RFC3819].
Using broadcast/multicast can become problematic if the information Using broadcast/multicast can become problematic if the information
that is being distributed can be regarded as sensitive or when the that is being distributed can be regarded as sensitive or when the
information that is distributed by multiple of these protocols can be information that is distributed by multiple of these protocols can be
correlated in a way that sensitive data can be derived. This is correlated in a way that sensitive data can be derived. This is
clearly true for any protocol, but broadcast/multicast is special in clearly true for any protocol, but broadcast/multicast is special in
at least two respects: at least two respects:
(a) The aforementioned large receiver group, consisting of receivers (a) The aforementioned large receiver group, consisting of receivers
unknown to the sender. This makes eavesdropping without special unknown to the sender. This makes eavesdropping without special
skipping to change at page 3, line 30 skipping to change at page 3, line 34
much easier. much easier.
Privacy considerations of IETF-specified protocols have received some Privacy considerations of IETF-specified protocols have received some
attention in the recent past (e.g. RFC 7721 [RFC7721] or RFC 7819 attention in the recent past (e.g. RFC 7721 [RFC7721] or RFC 7819
[RFC7819]). There is also general guidance available for document [RFC7819]). There is also general guidance available for document
authors on when and how to include a privacy considerations section authors on when and how to include a privacy considerations section
in their documents and on how to evaluate the privacy implications of in their documents and on how to evaluate the privacy implications of
Internet protocols [RFC6973]. RFC6973 also describes potential Internet protocols [RFC6973]. RFC6973 also describes potential
threats to privacy in great detail and lists terminology that is also threats to privacy in great detail and lists terminology that is also
used in this document. In contrast to RFC6973, this document used in this document. In contrast to RFC6973, this document
contains a number of privacy considerations especially for broadcast/ contains a number of privacy considerations especially for protocols
multicast protocol designers that are intended to reduce the that rely on broadcast/multicast, intended to reduce the likelihood
likelihood that a broadcast/multicast protocol can be misused to that a broadcast/multicast protocol can be misused to collect
collect sensitive data about devices, users and groups of users on a sensitive data about devices, users and groups of users on a
broadcast/multicast domain. broadcast/multicast domain.
The above mentioned considerations particularly apply to protocols The above mentioned considerations particularly apply to protocols
designed outside the IETF for two reasons. For one, non-standard designed outside the IETF - for two reasons. For one, non-standard
protocols will likely not receive operational attention and support protocols will likely not receive operational attention and support
in making them more secure such as e.g. DHCP snooping does for DHCP in making them more secure such as e.g. DHCP snooping does for DHCP
because they typically are not documented. The other reason is that because they typically are not documented. The other reason is that
these protocols have been designed in isolation, where a set of these protocols have been designed in isolation, where a set of
considerations to follow is useful in the absence of a larger considerations to follow is useful in the absence of a larger
community providing feedback. In particular, carelessly designed community providing feedback. In particular, carelessly designed
broadcast/multicast protocols can break privacy efforts at different protocols that use broadcast/multicast can break privacy efforts at
layers of the protocol stack such as MAC address or IP address different layers of the protocol stack such as MAC address or IP
randomization [RFC4941]. address randomization [RFC4941].
1.1. Types and usage of broadcast and multicast 1.1. Types and usage of broadcast and multicast
In IPv4, two major types of broadcast addresses exist, the limited In IPv4, two major types of broadcast addresses exist, the limited
broadcast which is defined as all-ones (255.255.255.255, defined in broadcast which is defined as all-ones (255.255.255.255, defined in
section 5.3.5.1 of [RFC1812]) and the directed broadcast with the section 5.3.5.1 of [RFC1812]) and the directed broadcast with the
given network prefix of an IP address and the host part of all-ones given network prefix of an IP address and the host part of all-ones
(defined in section 5.3.5.2. of [RFC1812]). Broadcast packets are (defined in section 5.3.5.2. of [RFC1812]). Broadcast packets are
received by all nodes in a subnetwork. Limited broadcasts never received by all nodes in a subnetwork. Limited broadcasts never
transit a router. The same is true for directed broadcasts by transit a router. The same is true for directed broadcasts by
skipping to change at page 4, line 50 skipping to change at page 4, line 50
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Privacy considerations 2. Privacy considerations
There are a few obvious and a few not necessarily obvious things There are a few obvious and a few not necessarily obvious things
designers of broadcast/multicast protocols should consider in respect designers of protocols utilizing broadcast/multicast should consider
to the privacy implications of their protocol. Most of these items in respect to the privacy implications of their protocol. Most of
are based on protocol behavior observed as part of experiments on these items are based on protocol behavior observed as part of
operational networks [TRAC2016]. experiments on operational networks [TRAC2016].
2.1. Message frequency 2.1. Message frequency
Frequent broadcast/multicast traffic caused by an application can Frequent broadcast/multicast traffic caused by an application can
give away user behavior and online connection times. This allows a give away user behavior and online connection times. This allows a
passive observer to potentially deduce a user's current activity passive observer to potentially deduce a user's current activity
(e.g. a game) and it allows to create an online profile (i.e. times (e.g. a game) and it allows to create an online profile (i.e. times
the user is on the network). The higher the frequency of these the user is on the network). The higher the frequency of these
messages and the duration of time these messages are sent, the more messages and the duration of time these messages are sent, the more
accurate this profile will be. Given that broadcasts/multicasts are accurate this profile will be. Given that broadcasts/multicasts are
skipping to change at page 5, line 35 skipping to change at page 5, line 35
also services used for local name resolution in modern operating also services used for local name resolution in modern operating
systems utilize broadcast/multicast protocols (e.g. mDNS, LLMNR or systems utilize broadcast/multicast protocols (e.g. mDNS, LLMNR or
NetBIOS) to announce for example their shares regularly and allow a NetBIOS) to announce for example their shares regularly and allow a
tracking of the online time of a device. tracking of the online time of a device.
If a protocol relies on frequent or periodic broadcast/multicast If a protocol relies on frequent or periodic broadcast/multicast
messages, the frequency SHOULD be chosen conservatively, in messages, the frequency SHOULD be chosen conservatively, in
particular if the messages contain persistent identifiers (see next particular if the messages contain persistent identifiers (see next
subsection). Also, intelligent message suppression mechanisms such subsection). Also, intelligent message suppression mechanisms such
as the ones employed in mDNS [RFC6762] SHOULD be implemented. The as the ones employed in mDNS [RFC6762] SHOULD be implemented. The
lower the frequency of broadcast messages, the harder traffic lower the frequency of broadcast messages, the harder passive traffic
analysis and surveillance becomes. analysis and surveillance becomes.
2.2. Persistent identifiers 2.2. Persistent identifiers
A few broadcast/multicast protocols observed in the wild make use of A few protocols that make use of broadcast/multicast messages
persistent identifiers. This includes the use of host names or more observed in the wild make use of persistent identifiers. This
abstract persistent identifiers such as a universally unique includes the use of host names or more abstract persistent
identifiers (UUID) or similar. These IDs, which e.g. identify the identifiers such as a universally unique identifiers (UUID) or
installation of a certain application might not change across updates similar. These IDs, which e.g. identify the installation of a
of the software and are therefore extremely long lived. This allows certain application might not change across updates of the software
a passive observer to track a user precisely if broadcast/multicast and are therefore extremely long lived. This allows a passive
messages are frequent. This is even true in case the IP and/or MAC observer to track a user precisely if broadcast/multicast messages
address changes. Such identifiers also allow two different are frequent. This is even true in case the IP and/or MAC address
interfaces (e.g. WiFi and Ethernet) to be correlated to the same changes. Such identifiers also allow two different interfaces (e.g.
device. If the application makes use of persistent identifiers for WiFi and Ethernet) to be correlated to the same device. If the
multiple installations of the same application for the same user, application makes use of persistent identifiers for multiple
this even allows to infer that different devices belong to the same installations of the same application for the same user, this even
user. allows to infer that different devices belong to the same user.
The aforementioned broadcast messages from a synchronization The aforementioned broadcast messages from a synchronization
mechanism of a popular application also included a persistent mechanism of a popular application also included a persistent
identifier in every broadcast. This identifier did never change identifier in every broadcast. This identifier did never change
after the application was installed and allowed to track a device after the application was installed and allowed to track a device
even when it changed its network interface or when it connected to a even when it changed its network interface or when it connected to a
different network. different network.
Persistent IDs are considered bad practice in general for broadcast Persistent IDs are considered bad practice in general for broadcast
and multicast communication, as persistent application layer IDs will and multicast communication, as persistent application layer IDs will
make efforts on lower layers to randomize identifiers (e.g. make efforts on lower layers to randomize identifiers (e.g.
[I-D.huitema-6man-random-addresses]) useless or at least much more [I-D.huitema-6man-random-addresses]) useless. When protocols that
difficult. When broadcast/multicast protocols need to make use of make use of broadcast/multicast need to make use of IDs, frequent
IDs, frequent rotations of these IDs SHOULD be considered to make rotations of these IDs SHOULD be considered to make user tracking
user tracking more difficult. more difficult.
2.3. Anticipate user behavior 2.3. Anticipate user behavior
A large number of users name their device after themselves, either A large number of users name their device after themselves, either
using their first name, last name or both. Often a host name using their first name, last name or both. Often a host name
includes the type, model or maker of a device, its function or includes the type, model or maker of a device, its function or
includes language specific information. Based on data gathered includes language specific information. Based on data gathered
during experiments performed at IETF meetings and at a large campus during experiments performed at IETF meetings and at a large campus
network, this appears currently to be prevalent user behavior network, this appears currently to be prevalent user behavior
[TRAC2016]. For protocols using the host name as part of the [TRAC2016]. For protocols using the host name as part of the
skipping to change at page 6, line 44 skipping to change at page 6, line 44
of a device is identified (as an interesting target) or properties of of a device is identified (as an interesting target) or properties of
the device are known (e.g. known vulnerabilities). the device are known (e.g. known vulnerabilities).
Some of the most commonly used operating systems include the name the Some of the most commonly used operating systems include the name the
user chooses for the user account during the installation process as user chooses for the user account during the installation process as
part of the host name of the device. The name of the operating part of the host name of the device. The name of the operating
system can also be included, revealing therefore two pieces of system can also be included, revealing therefore two pieces of
information, which can be regarded as private information if the host information, which can be regarded as private information if the host
name is used in broadcast/multicast messages. name is used in broadcast/multicast messages.
Where possible, the use of host names and other user provided Where possible, the use of host names and other user-provided
information in broadcast/multicast protocols SHOULD be avoided. If information in protocols making use of broadcast/multicast SHOULD be
only a persistent ID is needed, this can be generated randomly. An avoided. If all that is required is a persistent identifier (which
application might want to display the information it will broadcast SHOULD be avoided, see Section 2.2), this SHOULD be generated
on the LAN at install/config time, so the user is at least aware of randomly. An application might want to display the information it
the application's behavior. More host name considerations can be will broadcast on the LAN at install/config time, so the user is at
found in [I-D.ietf-intarea-hostname-practice]. More information on least aware of the application's behavior. More host name
user participation can be found in RFC 6973 [RFC6973]. considerations can be found in [RFC8117]. More information on user
participation can be found in RFC 6973 [RFC6973].
2.4. Consider potential correlation 2.4. Consider potential correlation
A large number of services and applications make use of the A large number of services and applications make use of the
broadcast/multicast mechanism. That means there are various sources broadcast/multicast mechanism. That means there are various sources
of information that are easily accessible by a passive observer. In of information that are easily accessible by a passive observer. In
isolation, the information these protocols reveal might seem isolation, the information these protocols reveal might seem
harmless, but given multiple such protocols, it might be possible to harmless, but given multiple such protocols, it might be possible to
correlate this information. E.g. a protocol that uses frequent correlate this information. E.g. a protocol that uses frequent
messages including a UUID to identify the particular installation messages including a UUID to identify the particular installation
skipping to change at page 7, line 26 skipping to change at page 7, line 28
correlated using e.g. the MAC address of the device's interface. correlated using e.g. the MAC address of the device's interface.
In the experiments described in [TRAC2016], it was possible to In the experiments described in [TRAC2016], it was possible to
correlate frequently sent broadcast messages that included a unique correlate frequently sent broadcast messages that included a unique
identifier with other broadcast/multicast messages containing identifier with other broadcast/multicast messages containing
usernames (e.g. mDNS, LLMNR or NetBIOS), but also relationships to usernames (e.g. mDNS, LLMNR or NetBIOS), but also relationships to
other users. This allowed to reveal the real identity of the users other users. This allowed to reveal the real identity of the users
of many devices but it also gave some information about their social of many devices but it also gave some information about their social
environment away. environment away.
A broadcast protocol designer should be aware of the fact that even A designer of a protocol that makes use of broadcast/multicast needs
if - in isolation - the information a protocol leaks seems harmless, to be aware of the fact that even if - in isolation - the information
there might be ways to correlate that information with other a protocol leaks seems harmless, there might be ways to correlate
broadcast protocol information to reveal sensitive information about that information with information from other protocols to reveal
a user. sensitive information about a user.
2.5. Configurability 2.5. Configurability
A lot of applications and services using broadcast/multicast A lot of applications and services relying on broadcast/multicast
protocols do not include the means to declare "safe" environments protocols do not include the means to declare "safe" environments
(e.g. based on the SSID of a WiFi network and the MAC addresses of (e.g. based on the SSID of a WiFi network and the MAC addresses of
the access points). E.g. a device connected to a public WiFi will the access points). E.g. a device connected to a public WiFi will
likely broadcast the same information as when connected to the home likely broadcast the same information as when connected to the home
network. It would be beneficial if certain behavior could be network. It would be beneficial if certain behavior could be
restricted to "safe" environments. restricted to "safe" environments.
A popular operating system e.g. allows the user to specify the trust A popular operating system e.g. allows the user to specify the trust
level of the network the device connects to, which for example level of the network the device connects to, which for example
restricts specific system services (using broadcast/multicast restricts specific system services (using broadcast/multicast
messages for their normal operation) to be used in untrusted messages for their normal operation) to be used in trusted networks
networks. Such functionality could implemented as part of an only. Such functionality could implemented as part of an
application. application.
An application developer making use of broadcasts/multicasts as part An application developer making use of broadcasts/multicasts as part
of the application SHOULD make the broadcast feature, if possible, of the application SHOULD make the broadcast feature, if possible,
configurable, so that potentially sensitive information does not leak configurable, so that potentially sensitive information does not leak
on public networks, where the threat to privacy is much larger. on public networks, where the threat to privacy is much larger.
3. Operational considerations 3. Operational considerations
Besides changing end-user behavior, choosing sensible defaults as an Besides changing end-user behavior, choosing sensible defaults as an
skipping to change at page 8, line 20 skipping to change at page 8, line 25
there are things that the network administrators/operators can do to there are things that the network administrators/operators can do to
limit the above mentioned problems. limit the above mentioned problems.
A feature not uncommonly found on access points e.g. is to filter A feature not uncommonly found on access points e.g. is to filter
broadcast and multicast traffic. This will potentially break certain broadcast and multicast traffic. This will potentially break certain
applications or some of their functionality but will also protect the applications or some of their functionality but will also protect the
users from potentially leaking sensitive information. users from potentially leaking sensitive information.
4. Summary 4. Summary
Increasingly, applications rely on broadcast and multicast messages. Increasingly, applications rely on protocols that send and receive
For some, broadcasts/multicasts are the basis of their application broadcast and multicast messages. For some, broadcasts/multicasts
logic, others use broadcasts/multicasts to improve certain aspects of are the basis of their application logic, others use broadcasts/
the application but are fully functional in case broadcasts/ multicasts to improve certain aspects of the application but are
multicasts fail. Irrespective of the role of broadcast and multicast fully functional in case broadcasts/multicasts fail. Irrespective of
messages for the application, the designers of protocols that make the role of broadcast and multicast messages for the application, the
use of them should be very careful in their protocol design because designers of protocols that make use of them should be very careful
of the special nature of broad- and multicast. in their protocol design because of the special nature of broadcast
and multicast.
It is not always possible to implement certain functionality via It is not always possible to implement certain functionality via
unicast, but in case a protocol designer chooses to rely on unicast, but in case a protocol designer chooses to rely on
broadcast/multicast, the following should be carefully considered: broadcast/multicast, the following should be carefully considered:
o IETF-specified protocols, such as mDNS [RFC6762], SHOULD be used o IETF-specified protocols, such as mDNS [RFC6762], SHOULD be used
if possible as operational support might exist to protect against if possible as operational support might exist to protect against
the leakage of private information. Also, for some protocols the leakage of private information. Also, for some protocols
privacy extensions are being specified, which can be used if privacy extensions are being specified, which can be used if
implemented. E.g. for DNS-SD privacy extensions are documented in implemented. E.g. for DNS-SD privacy extensions are documented in
skipping to change at page 8, line 49 skipping to change at page 9, line 9
o Using user-specified information inside broadcast/multicast o Using user-specified information inside broadcast/multicast
messages SHOULD be avoided, as users will often use personal messages SHOULD be avoided, as users will often use personal
information or other information aiding attackers, in particular information or other information aiding attackers, in particular
if the user is unaware about how that information is being used if the user is unaware about how that information is being used
o The use of persistent IDs in messages SHOULD be avoided, as this o The use of persistent IDs in messages SHOULD be avoided, as this
allows user tracking, correlation and potentially has a allows user tracking, correlation and potentially has a
devastating effect on other privacy protection mechanisms devastating effect on other privacy protection mechanisms
o If you really must use a broadcast/multicast protocol and cannot o If one really must design a new protocol relying on broadcast/
use an IETF-specified protocol, then: multicast and cannot use an IETF-specified protocol, then:
* You SHOULD be very conservative in how frequently you send * You SHOULD be very conservative in how frequently you send
messages as an effort in data minimization messages as an effort in data minimization
* You SHOULD seek advice from IETF-specified protocols such as * You SHOULD seek advice from IETF-specified protocols such as
message suppression in mDNS message suppression in mDNS
* You SHOULD try to design the protocol in a way that the * You SHOULD try to design the protocol in a way that information
information cannot be correlated with other information in sent in broadcast/multicast messages cannot be correlated with
broadcast/multicast messages information from other protocols using broadcast/multicast
* You SHOULD let the user configure safe environments if possible * You SHOULD let the user configure safe environments if possible
(e.g. based on the SSID) (e.g. based on the SSID)
5. Other considerations 5. Other considerations
Besides privacy implications, frequent broadcasting also represents a Besides privacy implications, frequent broadcasting also represents a
performance problem. In particular in certain wireless technologies performance problem. In particular in certain wireless technologies
such as 802.11, broadcast and multicast are transmitted at a much such as 802.11, broadcast and multicast are transmitted at a much
lower rate (the lowest common denominator rate) compared to unicast lower rate (the lowest common denominator rate) compared to unicast
and therefore have a much bigger impact on the overall available and therefore have a much bigger impact on the overall available
airtime [I-D.perkins-intarea-multicast-ieee802]. Further, it will airtime [I-D.perkins-intarea-multicast-ieee802]. Further, it will
limit the ability for devices to go to sleep if frequent broadcasts limit the ability for devices to go to sleep if frequent broadcasts
are being sent. A similar problem in respect to Router are being sent. A similar problem in respect to Router
Advertisements is addressed in Advertisements is addressed in
[I-D.ietf-v6ops-reducing-ra-energy-consumption]. In that respect [I-D.ietf-v6ops-reducing-ra-energy-consumption]. In that respect
broadcasts/multicast can be used for another class of attacks that broadcasts/multicast can be used for another class of attacks that is
not related to privacy. The potential impact on network performance not related to privacy. The potential impact on network performance
should nevertheless be considered by broadcast protocol designers. should nevertheless be considered when designing a protocol that
makes use of broadcast/multicast.
6. Acknowledgments 6. Acknowledgments
We would like to thank Eliot Lear, Joe Touch and Stephane Bortzmeyer We would like to thank Eliot Lear, Joe Touch and Stephane Bortzmeyer
for their valuable input to this document. for their valuable input to this document.
This work was partly supported by the European Commission under grant This work was partly supported by the European Commission under grant
agreement FP7-318627 mPlane. Support does not imply endorsement. agreement FP7-318627 mPlane. Support does not imply endorsement.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 10, line 33 skipping to change at page 10, line 44
[I-D.huitema-6man-random-addresses] [I-D.huitema-6man-random-addresses]
Huitema, C., "Implications of Randomized Link Layers Huitema, C., "Implications of Randomized Link Layers
Addresses for IPv6 Address Assignment", draft-huitema- Addresses for IPv6 Address Assignment", draft-huitema-
6man-random-addresses-03 (work in progress), March 2016. 6man-random-addresses-03 (work in progress), March 2016.
[I-D.ietf-dnssd-privacy] [I-D.ietf-dnssd-privacy]
Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- Huitema, C. and D. Kaiser, "Privacy Extensions for DNS-
SD", draft-ietf-dnssd-privacy-00 (work in progress), SD", draft-ietf-dnssd-privacy-00 (work in progress),
October 2016. October 2016.
[I-D.ietf-intarea-hostname-practice]
Huitema, C. and D. Thaler, "Current Hostname Practice
Considered Harmful", draft-ietf-intarea-hostname-
practice-00 (work in progress), October 2015.
[I-D.ietf-v6ops-reducing-ra-energy-consumption] [I-D.ietf-v6ops-reducing-ra-energy-consumption]
Yourtchenko, A. and L. Colitti, "Reducing energy Yourtchenko, A. and L. Colitti, "Reducing energy
consumption of Router Advertisements", draft-ietf-v6ops- consumption of Router Advertisements", draft-ietf-v6ops-
reducing-ra-energy-consumption-03 (work in progress), reducing-ra-energy-consumption-03 (work in progress),
November 2015. November 2015.
[I-D.perkins-intarea-multicast-ieee802] [I-D.perkins-intarea-multicast-ieee802]
Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,
"Multicast Considerations over IEEE 802 Wireless Media", "Multicast Considerations over IEEE 802 Wireless Media",
draft-perkins-intarea-multicast-ieee802-03 (work in draft-perkins-intarea-multicast-ieee802-03 (work in
skipping to change at page 12, line 29 skipping to change at page 12, line 34
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>. <http://www.rfc-editor.org/info/rfc7721>.
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy [RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819,
April 2016, <http://www.rfc-editor.org/info/rfc7819>. April 2016, <http://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>.
[TRAC2016] [TRAC2016]
Faath, M., Weisshaar, F., and R. Winter, "How Broadcast Faath, M., Weisshaar, F., and R. Winter, "How Broadcast
Data Reveals Your Identity and Social Graph", 7th Data Reveals Your Identity and Social Graph", 7th
International Workshop on TRaffic Analysis and International Workshop on TRaffic Analysis and
Characterization IEEE TRAC 2016, September 2016. Characterization IEEE TRAC 2016, September 2016.
Authors' Addresses Authors' Addresses
Rolf Winter Rolf Winter
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
 End of changes. 26 change blocks. 
78 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/