draft-ietf-intarea-broadcast-consider-04.txt   draft-ietf-intarea-broadcast-consider-05.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: March 2, 2018 Conntac GmbH Expires: April 28, 2018 Conntac GmbH
F. Weisshaar F. Weisshaar
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
August 29, 2017 October 25, 2017
Privacy considerations for IP broadcast and multicast protocol designers Privacy considerations for IP broadcast and multicast protocol designers
draft-ietf-intarea-broadcast-consider-04 draft-ietf-intarea-broadcast-consider-05
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, broadcast/multicast protocol designers
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 March 2, 2018. This Internet-Draft will expire on April 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
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 and 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]. That is not entirely surprising. As RFC 919 network [TRAC2016]. This trend is not entirely surprising. As RFC
[RFC0919] puts it, "The use of broadcasts [...] is a good base for 919 [RFC0919] puts it, "The use of broadcasts [...] is a good base
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 underlying 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:
skipping to change at page 3, line 23 skipping to change at page 3, line 23
(b) Encryption is more difficult when broadcast/multicast messages, (b) Encryption is more difficult when broadcast/multicast messages,
leaving content of these messages in the clear and making it leaving content of these messages in the clear and making it
easier to spoof and replay them. easier to spoof and replay them.
Given the above, privacy protection for protocols based on broadcast Given the above, privacy protection for protocols based on broadcast
or multicast communication is significantly more difficult compared or multicast communication is significantly more difficult compared
to unicast communication and at the same time invading the privacy is to unicast communication and at the same time invading the privacy is
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 7919 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. used in this document. In contrast to RFC6973, this document
contains a number of privacy considerations especially for broadcast/
multicast protocol designers that are intended to reduce the
likelihood that a broadcast/multicast protocol can be misused to
collect sensitive data about devices, users and groups of users on a
broadcast/multicast domain.
In contrast to RFC6973, this document contains a number of privacy The above mentioned considerations particularly apply to protocols
considerations especially for broadcast/multicast protocol designers designed outside the IETF for two reasons. For one, non-standard
that are intended to reduce the likelihood that a broadcast/multicast protocols will likely not receive operational attention and support
protocol can be misused to collect sensitive data about devices, in making them more secure such as e.g. DHCP snooping does for DHCP
users and groups of users on a broadcast/multicast domain. These because they typically are not documented. The other reason is that
considerations particularly apply to protocols designed outside the these protocols have been designed in isolation, where a set of
IETF for two reasons. For one, non-standard protocols will likely
not receive operational attention and support 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 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 broadcast/multicast protocols can break privacy efforts at different
layers of the protocol stack such as MAC address or IP address layers of the protocol stack such as MAC address or IP address
randomization [RFC4941]. 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
skipping to change at page 5, line 14 skipping to change at page 5, line 14
are based on protocol behavior observed as part of experiments on are based on protocol behavior observed as part of experiments on
operational networks [TRAC2016]. 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, the more accurate this profile will be. Given that messages and the duration of time these messages are sent, the more
broadcasts/multicasts are only visible in the same broadcast/ accurate this profile will be. Given that broadcasts/multicasts are
multicast domain, these messages also give the rough location of the only visible in the same broadcast/multicast domain, these messages
user away (e.g. a campus or building). also give the rough location of the user away (e.g. a campus or
building).
This behavior has e.g. been observed by a synchronization mechanism This behavior has e.g. been observed by a synchronization mechanism
of a popular application, where multiple messages have been sent per of a popular application, where multiple messages have been sent per
minute via broadcast. Given this behavior, it is possible to record 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 a device's time on the network with a sub-minute accuracy given only
the traffic of this single application installed on the device. But the traffic of this single application installed on the device. But
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.
skipping to change at page 9, line 30 skipping to change at page 9, line 30
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 can be used for another class of attacks that not related broadcasts/multicast can be used for another class of attacks that
to privacy. The potential impact on network performance should not related to privacy. The potential impact on network performance
nevertheless be considered by broadcast protocol designers. should nevertheless be considered by broadcast protocol designers.
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
 End of changes. 11 change blocks. 
28 lines changed or deleted 29 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/