draft-ietf-intarea-broadcast-consider-01.txt   draft-ietf-intarea-broadcast-consider-02.txt 
Internet Engineering Task Force R. Winter Internet Engineering Task Force R. Winter
Internet-Draft M. Faath Internet-Draft M. Faath
Intended status: Informational F. Weisshaar Intended status: Informational F. Weisshaar
Expires: May 4, 2017 University of Applied Sciences Augsburg Expires: August 17, 2017 University of Applied Sciences Augsburg
October 31, 2016 February 13, 2017
Privacy considerations for IP broadcast and multicast protocol designers Privacy considerations for IP broadcast and multicast protocol designers
draft-ietf-intarea-broadcast-consider-01 draft-ietf-intarea-broadcast-consider-02
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 38
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 May 4, 2017. This Internet-Draft will expire on August 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Privacy considerations . . . . . . . . . . . . . . . . . . . 3 2. Privacy considerations . . . . . . . . . . . . . . . . . . . 4
2.1. Message frequency . . . . . . . . . . . . . . . . . . . . 4 2.1. Message frequency . . . . . . . . . . . . . . . . . . . . 4
2.2. Persistent identifiers . . . . . . . . . . . . . . . . . 4 2.2. Persistent identifiers . . . . . . . . . . . . . . . . . 4
2.3. Anticipate user behavior . . . . . . . . . . . . . . . . 5 2.3. Anticipate user behavior . . . . . . . . . . . . . . . . 5
2.4. Consider potential correlation . . . . . . . . . . . . . 5 2.4. Consider potential correlation . . . . . . . . . . . . . 6
2.5. Configurability . . . . . . . . . . . . . . . . . . . . . 6 2.5. Configurability . . . . . . . . . . . . . . . . . . . . . 6
3. Operational considerations . . . . . . . . . . . . . . . . . 7 3. Operational considerations . . . . . . . . . . . . . . . . . 7
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Other considerations . . . . . . . . . . . . . . . . . . . . 8 5. Other considerations . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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. Application developers use broadcast/multicast auto-configuration or link-layer address lookup. Also application
messages to implement things like local service or peer discovery and developers use broadcast/multicast messages to implement things like
it appears that an increasing number of applications make use of it. local service or peer discovery and it appears that an increasing
And, as RFC 919 [RFC0919] puts it, "The use of broadcasts [...] is a number of applications make use of it [TRAC2016]. That is not
good base for many applications". entierly surprising. As RFC 919 [RFC0919] puts it, "The use of
broadcasts [...] is a good base for many applications". Broadcast
and multicast functionality in a subnetwork are therefore important
as a lack thereof renders the 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:
(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 7, line 35 skipping to change at page 7, line 40
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 the leakage of private information. Also, for some protocols
privacy extensions are being specified, which can be used if
implemented. E.g. for DNS-SD privacy extensions are documented in
[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
o Avoid persistent IDs in messages as this allows user tracking, o Avoid persistent IDs in messages as this allows user tracking,
correlation and potentially has a devastating effect on other correlation and potentially has a devastating effect on other
privacy protection mechanisms privacy protection mechanisms
skipping to change at page 9, line 7 skipping to change at page 9, line 18
8. Security Considerations 8. Security Considerations
This document deals with privacy-related considerations of broadcast- This document deals with privacy-related considerations of broadcast-
and multicast-based protocols. It contains advice for designers of and multicast-based protocols. It contains advice for designers of
such protocols to minimize the leakage of privacy-sensitive such protocols to minimize the leakage of privacy-sensitive
information. The intent of the advice is to make sure that information. The intent of the advice is to make sure that
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
existing mechanisms to protect multicast traffic such as the ones
defined in [RFC5374]. Examples of such applications can be found in
Appendix A. of [RFC5374]. Given the required infrastructure and
assumptions about these applications and the security infrastructure,
many applications will not be able to make use of such mechanisms.
9. Informative References 9. 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]
Huitema, C. and D. Kaiser, "Privacy Extensions for DNS-
SD", draft-ietf-dnssd-privacy-00 (work in progress),
October 2016.
[I-D.ietf-intarea-hostname-practice] [I-D.ietf-intarea-hostname-practice]
Huitema, C. and D. Thaler, "Current Hostname Practice Huitema, C. and D. Thaler, "Current Hostname Practice
Considered Harmful", draft-ietf-intarea-hostname- Considered Harmful", draft-ietf-intarea-hostname-
practice-00 (work in progress), October 2015. 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.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, DOI 10.17487/RFC3819, July 2004,
<http://www.rfc-editor.org/info/rfc3819>.
[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
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,
<http://www.rfc-editor.org/info/rfc5374>.
[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>.
 End of changes. 14 change blocks. 
16 lines changed or deleted 46 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/