draft-ietf-intarea-broadcast-consider-06.txt   draft-ietf-intarea-broadcast-consider-07.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: July 19, 2018 Conntac GmbH Expires: July 23, 2018 Conntac GmbH
F. Weisshaar F. Weisshaar
University of Applied Sciences Augsburg University of Applied Sciences Augsburg
January 15, 2018 January 19, 2018
Privacy considerations for protocols relying on IP broadcast and Privacy considerations for protocols relying on IP broadcast and
multicast multicast
draft-ietf-intarea-broadcast-consider-06 draft-ietf-intarea-broadcast-consider-07
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, designers of protocols that make use their content. Therefore, designers of protocols that make use
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 19, 2018. This Internet-Draft will expire on July 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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. Types and usage of broadcast and multicast . . . . . . . 4 1.1. Types and usage of broadcast and multicast . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Privacy considerations . . . . . . . . . . . . . . . . . . . 4 2. Privacy considerations . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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
privileges or a special location in the network trivial for privileges or a special location in the network trivial for
anybody in the broadcast/multicast domain. anybody in the same broadcast/multicast domain.
(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.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
Typical usage of these addresses include local service discovery Typical usage of these addresses include local service discovery
(e.g. mDNS [RFC6762] and LLMNR [RFC4795] make use of multicast), (e.g. mDNS [RFC6762] and LLMNR [RFC4795] make use of multicast),
autoconfiguration (e.g. DHCPv4 [RFC2131] uses broadcasts and DHCPv6 autoconfiguration (e.g. DHCPv4 [RFC2131] uses broadcasts and DHCPv6
[RFC3315] uses multicast addresses) and other vital network services [RFC3315] uses multicast addresses) and other vital network services
such as address resolution or duplicate address detection. But such as address resolution or duplicate address detection. But
besides these core network functions, also applications make use of besides these core network functions, also applications make use of
broadcast and multicast functionality, often implementing proprietary broadcast and multicast functionality, often implementing proprietary
protocols. In sum, these protocols distribute a diverse set of protocols. In sum, these protocols distribute a diverse set of
potentially privacy sensitive information to a large receiver group. potentially privacy sensitive information to a large receiver group.
To become a receiver, the only requirement is to be part of the same
subnetwork.
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
skipping to change at page 9, line 12 skipping to change at page 9, line 12
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 one really must design a new protocol relying on broadcast/ o If one really must design a new protocol relying on broadcast/
multicast and cannot 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 * the protocol SHOULD be very conservative in how frequently it
messages as an effort in data minimization sends messages as an effort in data minimization
* You SHOULD seek advice from IETF-specified protocols such as * it SHOULD make use of mechanisms implemented in IETF-specified
protocols that can be helpful in privacy protection such as
message suppression in mDNS message suppression in mDNS
* You SHOULD try to design the protocol in a way that information * it SHOULD be designed in a way that information sent in
sent in broadcast/multicast messages cannot be correlated with broadcast/multicast messages cannot be correlated with
information from other protocols using broadcast/multicast information from other protocols using broadcast/multicast
* You SHOULD let the user configure safe environments if possible * it SHOULD be possible to let the user configure "safe"
(e.g. based on the SSID) 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 Wifi)
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
 End of changes. 11 change blocks. 
13 lines changed or deleted 18 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/