draft-ietf-intarea-broadcast-consider-02.txt   draft-ietf-intarea-broadcast-consider-03.txt 
Internet Engineering Task Force R. Winter Internet Engineering Task Force R. Winter
Internet-Draft M. Faath Internet-Draft University of Applied Sciences Augsburg
Intended status: Informational F. Weisshaar Intended status: Informational M. Faath
Expires: August 17, 2017 University of Applied Sciences Augsburg Expires: November 30, 2017 Conntac GmbH
February 13, 2017 F. Weisshaar
University of Applied Sciences Augsburg
May 29, 2017
Privacy considerations for IP broadcast and multicast protocol designers Privacy considerations for IP broadcast and multicast protocol designers
draft-ietf-intarea-broadcast-consider-02 draft-ietf-intarea-broadcast-consider-03
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 38 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 August 17, 2017. This Internet-Draft will expire on November 30, 2017.
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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Types and usage of broadcast and multicast . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Privacy considerations . . . . . . . . . . . . . . . . . . . 4 2. Privacy considerations . . . . . . . . . . . . . . . . . . . 4
2.1. Message frequency . . . . . . . . . . . . . . . . . . . . 4 2.1. Message frequency . . . . . . . . . . . . . . . . . . . . 5
2.2. Persistent identifiers . . . . . . . . . . . . . . . . . 4 2.2. Persistent identifiers . . . . . . . . . . . . . . . . . 5
2.3. Anticipate user behavior . . . . . . . . . . . . . . . . 5 2.3. Anticipate user behavior . . . . . . . . . . . . . . . . 6
2.4. Consider potential correlation . . . . . . . . . . . . . 6 2.4. Consider potential correlation . . . . . . . . . . . . . 6
2.5. Configurability . . . . . . . . . . . . . . . . . . . . . 6 2.5. Configurability . . . . . . . . . . . . . . . . . . . . . 7
3. Operational considerations . . . . . . . . . . . . . . . . . 7 3. Operational considerations . . . . . . . . . . . . . . . . . 8
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Other considerations . . . . . . . . . . . . . . . . . . . . 8 5. Other considerations . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
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 and it appears that an increasing
number of applications make use of it [TRAC2016]. That is not number of applications make use of it [TRAC2016]. That is not
entierly surprising. As RFC 919 [RFC0919] puts it, "The use of entirely surprising. As RFC 919 [RFC0919] puts it, "The use of
broadcasts [...] is a good base for many applications". Broadcast broadcasts [...] is a good base for many applications". Broadcast
and multicast functionality in a subnetwork are therefore important and multicast functionality in a subnetwork are therefore important
as a lack thereof renders the protocols underlying these mechanisms as a lack thereof renders the protocols underlying these mechanisms
inoperable [RFC3819]. 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
skipping to change at page 3, line 42 skipping to change at page 3, line 47
not receive operational attention and support in making them more not receive operational attention and support in making them more
secure such as e.g. DHCP snooping does for DHCP because they secure such as e.g. DHCP snooping does for DHCP because they
typically are not documented. The other reason is that these typically are not documented. The other reason is that these
protocols have been designed in isolation, where a set of 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. Requirements Language 1.1. Types and usage of broadcast and multicast
In IPv4, two major types of broadcast addresses exist, the limited
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
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
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
solely relies on multicast [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
is reserved for this purpose called the Local Network Control Block
(224.0.0.0/24, defined in section 4 of [RFC5771]). 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]).
Typical usage of these addresses include local service discovery
(e.g. mDNS [RFC6762] and 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. But
besides these core network functions, also applications 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.
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 broadcast/multicast protocols should consider in respect
to the privacy implications of their protocol. Most of these items to the privacy implications of their protocol. Most of these items
skipping to change at page 5, line 13 skipping to change at page 6, line 5
true in case the IP and/or MAC address changes. Such identifiers true in case the IP and/or MAC address changes. Such identifiers
also allow two different interfaces (e.g. WiFi and Ethernet) to be also allow two different interfaces (e.g. WiFi and Ethernet) to be
correlated to the same device. If the application makes use of correlated to the same device. If the application makes use of
persistent identifiers for multiple installations of the same persistent identifiers for multiple installations of the same
application for the same user, this even allows to infer that application for the same user, this even allows to infer that
different devices belong to the same user. 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 installaed 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.
If a broadcast/multicast protocol relies on IDs to be transmitted, it If a broadcast/multicast protocol relies on IDs to be transmitted, it
SHOULD be considered if frequent ID rotations are possible in order SHOULD be considered if frequent ID rotations are possible in order
to make user tracking more difficult. Persistent IDs are considered to make user tracking more difficult. Persistent IDs are considered
bad practice in general for broadcast and multicast communication as bad practice in general for broadcast and multicast communication as
persistent application layer IDs will make efforts on lower layers to persistent application layer IDs will make efforts on lower layers to
randomize identifiers (e.g. [I-D.huitema-6man-random-addresses]) randomize identifiers (e.g. [I-D.huitema-6man-random-addresses])
useless or at least much more difficult. useless or at least much more difficult.
skipping to change at page 7, line 38 skipping to change at page 8, line 33
the application but are fully functional in case broadcasts/ the application but are fully functional in case broadcasts/
multicasts fail. Irrespective of the role of broadcast and multicast multicasts fail. Irrespective of the role of broadcast and multicast
messages for the application, the designers of protocols that make messages for the application, the designers of protocols that make
use of them should be very careful in their protocol design because use of them should be very careful in their protocol design because
of the special nature of broad- and multicast. of the special nature of broad- 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
[I-D.ietf-dnssd-privacy] [I-D.ietf-dnssd-privacy]
o Avoid using user-specified information inside broadcast/multicast o Avoid using user-specified information inside broadcast/multicast
messages as users will often use personal information or other messages as users will often use personal information or other
information aiding attackers, in particular if the user is unaware information aiding attackers, in particular if the user is unaware
about how that information is being used about how that information is being used
skipping to change at page 8, line 43 skipping to change at page 9, line 40
available airtime. Further, it will limit the ability for devices to available airtime. Further, it will limit the ability for devices to
go to sleep if frequent broadcasts are being sent. A similar problem go to sleep if frequent broadcasts are being sent. A similar problem
in respect to Router Advertisements is addressed in in respect to Router 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 can be used for another class of attacks that not related
to privacy. The potential impact on network performance should to privacy. The potential impact on network performance should
nevertheless be considered by broadcast protocol designers. nevertheless be considered by broadcast protocol designers.
6. Acknowledgments 6. Acknowledgments
We would like to thank Eliot Lear and Stephane Bortzmeyer for their We would like to thank Eliot Lear, Joe Touch and Stephane Bortzmeyer
input. 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
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
skipping to change at page 9, line 25 skipping to change at page 10, line 21
identities will remain anonymous and user tracking will be made identities will remain anonymous and user tracking will be made
difficult. difficult.
It should be noted that certain applications could make use of It should be noted that certain applications could make use of
existing mechanisms to protect multicast traffic such as the ones existing mechanisms to protect multicast traffic such as the ones
defined in [RFC5374]. Examples of such applications can be found in defined in [RFC5374]. Examples of such applications can be found in
Appendix A. of [RFC5374]. Given the required infrastructure and Appendix A. of [RFC5374]. Given the required infrastructure and
assumptions about these applications and the security infrastructure, assumptions about these applications and the security infrastructure,
many applications will not be able to make use of such mechanisms. many applications will not be able to make use of such mechanisms.
9. Informative References 9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[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.
skipping to change at page 10, line 5 skipping to change at page 11, line 9
[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.
[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC
919, DOI 10.17487/RFC0919, October 1984, 919, DOI 10.17487/RFC0919, October 1984,
<http://www.rfc-editor.org/info/rfc919>. <http://www.rfc-editor.org/info/rfc919>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 1812, DOI 10.17487/RFC1812, June 1995,
<http://www.rfc-editor.org/info/rfc1812>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, DOI 10.17487/RFC2131, March 1997,
<http://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, <http://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, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, DOI 10.17487/RFC3819, July 2004, RFC 3819, DOI 10.17487/RFC3819, July 2004,
<http://www.rfc-editor.org/info/rfc3819>. <http://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, <http://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,
<http://www.rfc-editor.org/info/rfc4795>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,
<http://www.rfc-editor.org/info/rfc5374>. <http://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,
<http://www.rfc-editor.org/info/rfc5771>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, DOI Considerations for Internet Protocols", RFC 6973, DOI
10.17487/RFC6973, July 2013, 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>. <http://www.rfc-editor.org/info/rfc6973>.
skipping to change at page 11, line 15 skipping to change at page 12, line 45
Authors' Addresses Authors' Addresses
Rolf Winter Rolf Winter
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
Augsburg Augsburg
DE DE
Email: rolf.winter@hs-augsburg.de Email: rolf.winter@hs-augsburg.de
Michael Faath Michael Faath
University of Applied Sciences Augsburg Conntac GmbH
Augsburg Augsburg
DE DE
Email: michael.faath@hs-augsburg.de Email: faath@conntac.net
Fabian Weisshaar Fabian Weisshaar
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
Augsburg Augsburg
DE DE
Email: fabian.weisshaar@hs-augsburg.de Email: fabian.weisshaar@hs-augsburg.de
 End of changes. 18 change blocks. 
30 lines changed or deleted 105 lines changed or added

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