[要約] RFC 8386は、IPブロードキャストやマルチキャストに依存するプロトコルに関するプライバシーの考慮事項をまとめたものです。このRFCの目的は、ネットワークプロトコルの設計者や開発者がプライバシー保護を考慮した設計を行うためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) R. Winter
Request for Comments: 8386 University of Applied Sciences Augsburg
Category: Informational M. Faath
ISSN: 2070-1721 Conntac GmbH
F. Weisshaar
University of Applied Sciences Augsburg
May 2018
Privacy Considerations for Protocols Relying on IP Broadcast or Multicast
IPブロードキャストまたはマルチキャストに依存するプロトコルのプライバシーに関する考慮事項
Abstract
概要
A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content. Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols.
多くのアプリケーション層プロトコルは、ローカルサービス検出や名前解決などの機能にIPブロードキャストまたはマルチキャストメッセージを利用します。これらの機能の一部は、そのようなメカニズムを使用してのみ効率的に実装できます。ブロードキャストメッセージまたはマルチキャストメッセージを使用する場合、同じブロードキャストドメインまたはマルチキャストドメイン内のパッシブオブザーバーは、これらのメッセージを簡単に記録し、その内容を分析できます。したがって、ブロードキャストまたはマルチキャストメッセージを利用するプロトコルの設計者は、プロトコルの設計時に特別な注意を払う必要があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8386.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8386で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Types and Usage of Broadcast and Multicast .................4
1.2. Requirements Language ......................................5
2. Privacy Considerations ..........................................5
2.1. Message Frequency ..........................................5
2.2. Persistent Identifiers .....................................6
2.3. Anticipate User Behavior ...................................6
2.4. Consider Potential Correlation .............................7
2.5. Configurability ............................................7
3. Operational Considerations ......................................8
4. Summary .........................................................8
5. Other Considerations ............................................9
6. IANA Considerations ............................................10
7. Security Considerations ........................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Acknowledgments ...................................................13
Authors' Addresses ................................................13
Broadcast and multicast messages have a large (and, to the sender, unknown) receiver group by design. Because of that, these two mechanisms are vital for a number of basic network functions such as autoconfiguration and link-layer address lookup. Also, application developers use broadcast/multicast messages to implement things such as local service or peer discovery. It appears that an increasing number of applications make use of it as suggested by experimental results obtained on campus networks, including the IETF meeting network [TRAC2016]. This trend is not entirely surprising. As
ブロードキャストおよびマルチキャストメッセージには、設計上、大きな（そして送信者にとっては不明な）受信者グループがあります。そのため、これら2つのメカニズムは、自動構成やリンク層アドレス検索など、いくつかの基本的なネットワーク機能に不可欠です。また、アプリケーション開発者はブロードキャスト/マルチキャストメッセージを使用して、ローカルサービスやピアディスカバリなどを実装します。 IETFミーティングネットワーク[TRAC2016]を含むキャンパスネットワークで得られた実験結果が示唆するように、それを利用するアプリケーションの数は増加しているようです。この傾向はまったく驚くべきことではありません。なので
[RFC919] puts it, "The use of broadcasts [...] is a good base for many applications". Broadcast and multicast functionality in a subnetwork is therefore important because a lack thereof renders the protocols relying on these mechanisms inoperable [RFC3819].
[RFC919]は、「ブロードキャストの使用[...]は、多くのアプリケーションにとって良いベースである」と述べています。したがって、サブネットワークでのブロードキャストおよびマルチキャスト機能は、これらのメカニズムに依存するプロトコルを動作不能にする[RFC3819]ため、重要です。
Using broadcast/multicast can become problematic if the information that is being distributed can be regarded as sensitive or if the information that is distributed by multiple protocols can be correlated in a way that sensitive data can be derived. This is clearly true for any protocol, but broadcast/multicast is special in at least two respects:
配信されている情報を機密と見なすことができる場合、または複数のプロトコルによって配信された情報を機密データを導き出す方法で相互に関連付けることができる場合、ブロードキャスト/マルチキャストの使用は問題になる可能性があります。これは明らかにどのプロトコルにも当てはまりますが、ブロードキャスト/マルチキャストは少なくとも2つの点で特別です。
(a) The aforementioned large receiver group consists of receivers unknown to the sender. This makes eavesdropping without special privileges or a special location in the network trivial for anybody in the same broadcast/multicast domain.
（a）前述の大きな受信者グループは、送信者にとって未知の受信者で構成されています。これにより、特別な権限やネットワーク内の特別な場所がなくても、同じブロードキャスト/マルチキャストドメインの誰にとっても盗聴が簡単になります。
(b) Encryption is difficult when broadcast/multicast messages are used, because, for instance, a non-trivial key management protocol might be required. When encryption is not used, the content of these messages is easily accessible, making it easy to spoof and replay them.
（b）ブロードキャスト/マルチキャストメッセージを使用する場合、暗号化は困難です。たとえば、重要なキー管理プロトコルが必要になる場合があるためです。暗号化を使用しない場合、これらのメッセージのコンテンツに簡単にアクセスできるため、簡単になりすましや再生を行うことができます。
Given the above, privacy protection for protocols based on broadcast or multicast communication is significantly more difficult compared to unicast communication, and at the same time, invasion of privacy is much easier.
上記のことから、ブロードキャストまたはマルチキャスト通信に基づくプロトコルのプライバシー保護は、ユニキャスト通信に比べてはるかに困難であると同時に、プライバシーの侵害がはるかに容易です。
Privacy considerations for IETF-specified protocols have received some attention in the recent past (e.g., [RFC7721] and [RFC7819]). There is also general guidance available for document authors on when and how to include a privacy considerations section in their documents and on how to evaluate the privacy implications of Internet protocols [RFC6973]. RFC 6973 also describes potential threats to privacy in great detail and lists terminology that is also used in this document. In contrast to RFC 6973, this document contains a number of privacy considerations, especially for protocols that rely on broadcast/multicast, that are intended to reduce the likelihood that a broadcast- or multicast-based protocol can be misused to collect sensitive data about devices, users, and groups of users in a broadcast/multicast domain.
IETFで指定されたプロトコルのプライバシーに関する考慮事項は、最近注目を集めています（たとえば、[RFC7721]および[RFC7819]）。また、ドキュメントの作成者がプライバシーに関する考慮事項のセクションをいつどのようにドキュメントに含めるか、およびインターネットプロトコルのプライバシーへの影響を評価する方法に関する一般的なガイダンスもあります[RFC6973]。 RFC 6973は、プライバシーに対する潜在的な脅威についても詳しく説明し、このドキュメントでも使用されている用語をリストしています。 RFC 6973とは対照的に、このドキュメントには、特にブロードキャスト/マルチキャストに依存するプロトコルに関して、ブロードキャストまたはマルチキャストベースのプロトコルがデバイスに関する機密データを収集するために誤用される可能性を減らすことを目的とした、いくつかのプライバシーに関する考慮事項が含まれています、ユーザー、およびブロードキャスト/マルチキャストドメイン内のユーザーグループ。
The above-mentioned considerations particularly apply to protocols designed outside the IETF for two reasons. First, non-standard protocols will likely not receive operational attention and support in making them more secure, e.g., what DHCP snooping does for DHCP. Because these protocols are typically not documented, network equipment does not provide similar features for them. Second, these protocols have been designed in isolation, where a set of considerations to follow is useful in the absence of a larger community providing feedback and expertise to improve the protocol. In particular, carelessly designed protocols that use broadcast/ multicast can break privacy efforts at different layers of the protocol stack such as Media Access Control (MAC) address or IP address randomization [RFC4941].
上記の考慮事項は、IETFの外部で設計されたプロトコルに2つの理由で特に当てはまります。第1に、非標準プロトコルは、たとえばDHCPスヌーピングがDHCPに対して行うことなど、それらをより安全にするための運用上の注意やサポートを受けない可能性があります。これらのプロトコルは通常文書化されていないため、ネットワーク機器は同様の機能を提供していません。第2に、これらのプロトコルは分離して設計されているため、プロトコルを改善するためのフィードバックと専門知識を提供するより大きなコミュニティがない場合、従うべき一連の考慮事項が役立ちます。特に、ブロードキャスト/マルチキャストを使用する不注意に設計されたプロトコルは、メディアアクセスコントロール（MAC）アドレスやIPアドレスのランダム化[RFC4941]など、プロトコルスタックのさまざまなレイヤーでプライバシーの取り組みを壊す可能性があります。
In IPv4, two major types of broadcast addresses exist: limited broadcast and directed broadcast. Section 5.3.5 of [RFC1812] defines limited broadcast as all-ones (255.255.255.255) and defines directed broadcast as the given network prefix of an IP address and the local part of all-ones. 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 relies solely on multicast [RFC4291].
IPv4では、2つの主要なタイプのブロードキャストアドレスが存在します。限定ブロードキャストとダイレクトブロードキャストです。 [RFC1812]のセクション5.3.5は、限定ブロードキャストをオールワン（255.255.255.255）として定義し、ダイレクトブロードキャストをIPアドレスの特定のネットワークプレフィックスおよびオールワンのローカル部分として定義しています。ブロードキャストパケットは、サブネットワーク内のすべてのノードで受信されます。限られたブロードキャストはルーターを通過しません。デフォルトはダイレクトブロードキャストにも同じですが、ルーターはこれを行うオプションを提供する場合があります[RFC2644]。一方、IPv6はブロードキャストアドレスを提供しませんが、マルチキャストのみに依存します[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 called the "Local Network Control Block" (224.0.0.0/24, defined in Section 4 of [RFC5771]) is reserved for this purpose. 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]).
ブロードキャストアドレスとは対照的に、マルチキャストアドレスは、サブネットワーク内のすべてのノードとは異なるセットである可能性があるインターフェイスのセットの識別子を表します。特定のマルチキャストアドレスで識別されるすべてのインターフェイスは、そのアドレス宛てのパケットを受信し、「マルチキャストグループ」と呼ばれます。 IPv4とIPv6の両方で、複数の事前定義されたマルチキャストアドレスが存在します。このドキュメントに最も関連するのは、サブネットスコープを持つものです。 IPv4の場合、「ローカルネットワーク制御ブロック」（224.0.0.0/24、[RFC5771]のセクション4で定義）と呼ばれるIPプレフィックスがこの目的のために予約されています。 IPv6の場合、関連するマルチキャストアドレスは2つのAll Nodes Addressesであり、すべてのIPv6対応ホストが自身を識別するものとして認識する必要があります（[RFC4291]のセクション2.7.1を参照）。
Typical usage of these addresses includes local service discovery (e.g., Multicast DNS (mDNS) [RFC6762] and Link-Local Multicast Name Resolution (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. Aside from these core network functions, applications also 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, and the only requirement to be part of this receiver group is to be on the same subnetwork.
これらのアドレスの一般的な使用法には、ローカルサービスディスカバリ（たとえば、マルチキャストDNS（mDNS）[RFC6762]とリンクローカルマルチキャスト名前解決（LLMNR）[RFC4795]はマルチキャストを利用）、自動構成（たとえば、DHCPv4 [RFC2131]はブロードキャストを使用） DHCPv6 [RFC3315]はマルチキャストアドレスを使用します）、およびアドレス解決や重複アドレス検出などのその他の重要なネットワークサービス。これらのコアネットワーク機能の他に、アプリケーションはブロードキャストおよびマルチキャスト機能も利用し、多くの場合、独自のプロトコルを実装しています。要約すると、これらのプロトコルは、プライバシーに敏感な可能性のあるさまざまな情報のセットを大規模な受信者グループに配信し、この受信者グループの一部であるための唯一の要件は、同じサブネットワーク上にあることです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
There are a few obvious and a few not necessarily obvious things that designers of protocols utilizing broadcast/multicast should consider in respect to the privacy implications for their protocol. Most of these items are based on protocol behavior observed as part of experiments on operational networks [TRAC2016].
ブロードキャスト/マルチキャストを利用するプロトコルの設計者が、それらのプロトコルのプライバシーへの影響に関して考慮すべきいくつかの明白な事項と必ずしも明確ではない事項があります。これらの項目のほとんどは、運用ネットワークの実験の一部として観察されたプロトコルの動作に基づいています[TRAC2016]。
Frequent broadcast/multicast traffic caused by an application can give away user behavior and online connection times. This allows a passive observer to potentially deduce a user's current activity (e.g., a game) and to create an online profile (i.e., times the user is on the network). This profile becomes more accurate as the frequency of messages and the time duration over which they are sent increases. Given that broadcast/multicast messages are only visible in the same broadcast/multicast domain, these messages also give away the rough location of the user (e.g., a campus or building).
アプリケーションによって頻繁に発生するブロードキャスト/マルチキャストトラフィックは、ユーザーの行動とオンライン接続時間を解放する可能性があります。これにより、パッシブオブザーバーはユーザーの現在のアクティビティ（ゲームなど）を推定し、オンラインプロファイルを作成できます（つまり、ユーザーがネットワーク上にいる時間）。このプロファイルは、メッセージの頻度とメッセージが送信される期間が長くなるほど正確になります。ブロードキャスト/マルチキャストメッセージは同じブロードキャスト/マルチキャストドメインでのみ表示されるため、これらのメッセージはユーザー（キャンパスや建物など）のおおよその位置も知らせます。
This behavior has, for example, been observed by a synchronization mechanism of a popular application, where multiple messages have been sent per 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 the traffic of this single application installed on the device. Also, services used for local name resolution in modern operating systems utilize broadcast- or multicast-based protocols (e.g., mDNS, LLMNR, or NetBIOS) to announce, for example, resources on a regular basis. This also allows tracking of the online times of a device.
この動作は、たとえば、一般的なアプリケーションの同期メカニズムによって確認されています。このアプリケーションでは、1分間に複数のメッセージがブロードキャストで送信されます。この動作により、デバイスにインストールされているこの1つのアプリケーションのトラフィックのみが与えられた場合、ネットワーク上のデバイスの時間を1分未満の精度で記録することができます。また、最新のオペレーティングシステムでローカルの名前解決に使用されるサービスは、ブロードキャストベースまたはマルチキャストベースのプロトコル（mDNS、LLMNR、NetBIOSなど）を使用して、たとえば定期的にリソースをアナウンスします。これにより、デバイスのオンライン時間を追跡することもできます。
If a protocol relies on frequent or periodic broadcast/multicast messages, the frequency SHOULD be chosen conservatively, in particular if the messages contain persistent identifiers (see Section 2.2). Also, intelligent message suppression mechanisms such as the ones employed in mDNS [RFC6762] SHOULD be implemented. The lower the frequency of broadcast messages, the harder passive traffic analysis and surveillance becomes.
プロトコルが頻繁または定期的なブロードキャスト/マルチキャストメッセージに依存している場合、特にメッセージに永続的な識別子が含まれている場合は、頻度を控えめに選択する必要があります（セクション2.2を参照）。また、mDNS [RFC6762]で採用されているようなインテリジェントなメッセージ抑制メカニズムを実装する必要があります（SHOULD）。ブロードキャストメッセージの頻度が低いほど、パッシブトラフィックの分析と監視が難しくなります。
A few protocols that make use of broadcast/multicast messages observed in the wild also make use of persistent identifiers. This includes the use of host names or more abstract persistent identifiers such as a Universally Unique Identifiers (UUIDs) or similar. These IDs, which, for example, identify the installation of a certain application, might not change across updates of the software and can therefore be extremely long lived. This allows a passive observer to track a user precisely if broadcast/multicast messages are frequent. This is even true if the IP and/or MAC address changes. Such identifiers also allow two different interfaces (e.g., Wi-Fi and Ethernet) to be correlated to the same device. If the application makes use of persistent identifiers for multiple installations of the same application for the same user, this even allows a passive observer to infer that different devices belong to the same user.
野生で観測されたブロードキャスト/マルチキャストメッセージを利用するいくつかのプロトコルは、永続的な識別子も利用します。これには、ホスト名や、Universally Unique Identifiers（UUID）などのより抽象的な永続的な識別子の使用が含まれます。たとえば、特定のアプリケーションのインストールを識別するこれらのIDは、ソフトウェアの更新によって変更されない可能性があるため、非常に長寿命になる可能性があります。これにより、ブロードキャスト/マルチキャストメッセージが頻繁に発生する場合に、パッシブオブザーバーがユーザーを正確に追跡できます。これは、IPアドレスやMACアドレスが変更された場合にも当てはまります。このような識別子により、2つの異なるインターフェース（Wi-Fiとイーサネットなど）を同じデバイスに関連付けることもできます。アプリケーションが同じユーザーの同じアプリケーションの複数のインストールに永続的な識別子を使用する場合、これによりパッシブオブザーバーは異なるデバイスが同じユーザーに属していると推測することもできます。
The aforementioned broadcast messages from a synchronization mechanism of a popular application also included a persistent identifier in every broadcast. This identifier never changed after the application was installed, which allowed for the tracking of a device even when it changed its network interface or when it connected to a different network.
一般的なアプリケーションの同期メカニズムからの前述のブロードキャストメッセージにも、すべてのブロードキャストに永続的な識別子が含まれていました。この識別子はアプリケーションがインストールされた後は変更されなかったため、ネットワークインターフェイスを変更したり、別のネットワークに接続したりした場合でも、デバイスを追跡できました。
In general, persistent IDs are considered bad practice for broadcast and multicast communication, as persistent application-layer IDs will make efforts to randomize identifiers (e.g., [RANDOM-ADDR]) on lower layers useless. When protocols that make use of broadcast/multicast need to make use of IDs, these IDs SHOULD be rotated frequently to make user tracking more difficult.
一般に、永続的なアプリケーションレイヤーIDは下位レイヤーの識別子（[RANDOM-ADDR]など）をランダム化しようとするため、永続的なIDはブロードキャストおよびマルチキャスト通信の悪い習慣と見なされます。ブロードキャスト/マルチキャストを使用するプロトコルがIDを使用する必要がある場合、これらのIDを頻繁にローテーションして、ユーザーの追跡をより困難にする必要があります。
A large number of users name their device after themselves, either using their first name, last name, or both. Often, a host name includes the type, model, or maker of a device, its function, or language-specific information. Based on data gathered during experiments performed at IETF meetings and at a large campus network, this appears to be the currently prevalent user behavior [TRAC2016]. For protocols using the host name as part of the messages, this clearly will reveal personally identifiable information to everyone on the local network. This information can also be used to mount more sophisticated attacks, e.g., when the owner of a device is identified (as an interesting target) or properties of the device are known (e.g., known vulnerabilities). Host names are also a type of persistent identifier; therefore, the considerations in Section 2.2 apply.
多数のユーザーが、名、姓、またはその両方を使用して、自分にちなんでデバイスに名前を付けています。多くの場合、ホスト名には、デバイスのタイプ、モデル、またはメーカー、その機能、または言語固有の情報が含まれます。 IETFの会議や大規模なキャンパスネットワークで行われた実験中に収集されたデータに基づくと、これは現在普及しているユーザー行動[TRAC2016]のようです。メッセージの一部としてホスト名を使用するプロトコルの場合、これにより、ローカルネットワーク上のすべての人に個人を特定できる情報が明らかになります。この情報は、たとえば、デバイスの所有者が（興味深いターゲットとして）識別された場合や、デバイスのプロパティが既知の場合（既知の脆弱性など）に、より高度な攻撃を仕掛けるために使用することもできます。ホスト名も永続的な識別子の一種です。したがって、セクション2.2の考慮事項が適用されます。
Some of the most commonly used operating systems include the name the user chooses for the user account during the installation process as part of the host name of the device. The name of the operating system can also be included, therefore revealing two pieces of information that can be regarded as private information if the host name is used in broadcast/multicast messages.
最も一般的に使用されているオペレーティングシステムには、デバイスのホスト名の一部として、インストールプロセス中にユーザーがユーザーアカウント用に選択した名前が含まれています。オペレーティングシステムの名前も含めることができるため、ブロードキャスト/マルチキャストメッセージでホスト名が使用されている場合、プライベート情報と見なすことができる2つの情報が明らかになります。
Where possible, the use of host names and other user-provided information in protocols making use of broadcast/multicast SHOULD be avoided. An application might want to display the information it will broadcast on the LAN at install/config time, so that the user is at least aware of the application's behavior. More host name considerations can be found in [RFC8117]. More information on user participation can be found in [RFC6973].
可能であれば、ブロードキャスト/マルチキャストを利用するプロトコルでのホスト名やその他のユーザー提供情報の使用は避けてください。アプリケーションは、ユーザーが少なくともアプリケーションの動作を認識できるように、インストール/構成時にLANでブロードキャストする情報を表示したい場合があります。ホスト名に関するその他の考慮事項は、[RFC8117]にあります。ユーザー参加の詳細については、[RFC6973]を参照してください。
A large number of services and applications make use of the broadcast/multicast mechanism. That means there are various sources of information that are easily accessible by a passive observer. In isolation, the information these protocols reveal might seem harmless, but given multiple such protocols, it might be possible to correlate this information. For example, a protocol that uses frequent messages including a UUID to identify the particular installation does not give away the identity of the user. However, a single message including the user's host name might do that, and it can be correlated using, for example, the MAC address of the device's interface.
多数のサービスとアプリケーションがブロードキャスト/マルチキャストメカニズムを利用しています。つまり、受動的な観測者が簡単にアクセスできるさまざまな情報源があるということです。個別に、これらのプロトコルが明らかにする情報は無害に見えるかもしれませんが、複数のそのようなプロトコルが与えられた場合、この情報を関連付けることが可能かもしれません。たとえば、特定のインストールを識別するためにUUIDを含む頻繁なメッセージを使用するプロトコルは、ユーザーのIDを提供しません。ただし、ユーザーのホスト名を含む単一のメッセージがそれを行う可能性があり、たとえば、デバイスのインターフェースのMACアドレスを使用してそれを関連付けることができます。
In the experiments described in [TRAC2016], it was possible to correlate frequently sent broadcast messages that included a unique identifier with other broadcast/multicast messages containing usernames (e.g. mDNS, LLMNR, or NetBIOS); this revealed relationships among users. This allowed the real identity of the users of many devices to be revealed, and it also gave away some information about their social environment.
[TRAC2016]で説明されている実験では、一意の識別子を含む頻繁に送信されるブロードキャストメッセージを、ユーザー名（mDNS、LLMNR、NetBIOSなど）を含む他のブロードキャスト/マルチキャストメッセージと関連付けることができました。これにより、ユーザー間の関係が明らかになりました。これにより、多くのデバイスのユーザーの本当のアイデンティティを明らかにすることができ、彼らの社会的環境に関する情報も提供されました。
A designer of a protocol that makes use of broadcast/multicast needs to be aware of the fact that even if the information a protocol leaks seems harmless in isolation, there might be ways to correlate that information with information from other protocols to reveal sensitive information about a user.
ブロードキャスト/マルチキャストを利用するプロトコルの設計者は、プロトコルが漏洩する情報が単独では無害であるように見えても、その情報を他のプロトコルからの情報と関連付けて機密情報を明らかにする方法があるかもしれないという事実を認識する必要がありますユーザー。
A lot of applications and services relying on broadcast- or multicast-based protocols do not include the means to declare "safe" environments (e.g., based on the Service Set Identifier (SSID) of a Wi-Fi network and the MAC addresses of the access points). For example, a device connected to a public Wi-Fi network will likely broadcast the same information as when connected to the home network. It would be beneficial if certain behaviors could be restricted to "safe" environments.
ブロードキャストまたはマルチキャストベースのプロトコルに依存する多くのアプリケーションとサービスには、「安全な」環境を宣言する手段が含まれていません（たとえば、Wi-Fiネットワークのサービスセット識別子（SSID）とアクセスポイント）。たとえば、公衆Wi-Fiネットワークに接続されているデバイスは、ホームネットワークに接続されているときと同じ情報をブロードキャストする可能性があります。特定の動作を「安全な」環境に制限できれば有益です。
For example, a popular operating system allows the user to specify the trust level of the network the device connects to, which, for example, restricts specific system services (using broadcast/ multicast messages for their normal operation) to be used in trusted networks only. Such functionality could be implemented as part of an application.
たとえば、一般的なオペレーティングシステムでは、ユーザーがデバイスが接続するネットワークの信頼レベルを指定できます。これにより、たとえば、信頼できるネットワークでのみ使用される特定のシステムサービス（通常の操作にブロードキャスト/マルチキャストメッセージを使用）が制限されます。 。このような機能は、アプリケーションの一部として実装できます。
An application developer making use of broadcast/multicast messages as part of the application SHOULD, if possible, make the broadcast feature configurable so that potentially sensitive information does not leak on public networks where the threat to privacy is much larger.
アプリケーションの一部としてブロードキャスト/マルチキャストメッセージを利用するアプリケーション開発者は、可能であれば、ブロードキャスト機能を構成可能にして、プライバシーに対する脅威がはるかに大きいパブリックネットワーク上で機密情報が漏洩しないようにする必要があります。
Besides changing end-user behavior, choosing sensible defaults as an operating system vendor (e.g., for suggesting host names), and following the considerations for protocol designers mentioned in this document, there is something that the network administrators/ operators can do to limit the above-mentioned problems.
エンドユーザーの動作を変更することに加えて、オペレーティングシステムベンダーとして適切なデフォルトを選択し（たとえば、ホスト名を提案するため）、このドキュメントで言及されているプロトコルデザイナーの考慮事項に従って、ネットワーク管理者/オペレーターが制限することができるものがあります。上記の問題。
A feature commonly found on access points is the ability to manage/ filter broadcast and multicast traffic. This will potentially break certain applications or some of their functionality but will also protect the users from potentially leaking sensitive information. Wireless access points often provide finer-grained control beyond a simple on/off switch for well-known protocols or provide mechanisms to manage broadcast/multicast traffic intelligently using, for example, proxies (see [MCAST-CONS]). However, these mechanisms only work on standardized protocols.
アクセスポイントで一般的に見られる機能は、ブロードキャストおよびマルチキャストトラフィックを管理/フィルタリングする機能です。これにより、特定のアプリケーションまたはその機能の一部が破壊される可能性がありますが、機密情報の漏洩からユーザーを保護することにもなります。ワイヤレスアクセスポイントは、よく知られたプロトコルの単純なオン/オフスイッチを超えて、よりきめ細かい制御を提供したり、プロキシなどを使用してブロードキャスト/マルチキャストトラフィックをインテリジェントに管理するメカニズムを提供したりします（[MCAST-CONS]を参照）。ただし、これらのメカニズムは標準化されたプロトコルでのみ機能します。
Increasingly, applications rely on protocols that send and receive broadcast and multicast messages. For some, broadcast/multicast messages are the basis of their application logic; others use broadcast/multicast messages to improve certain aspects of the application but are fully functional in case broadcast/multicast messages fail. Irrespective of the role of broadcast and multicast messages for the application, the designers of protocols that make use of them should be very careful in their protocol design because of the special nature of broadcast and multicast.
アプリケーションは、ブロードキャストおよびマルチキャストメッセージを送受信するプロトコルにますます依存しています。一部の人にとって、ブロードキャスト/マルチキャストメッセージは、それらのアプリケーションロジックの基礎です。他のアプリケーションは、アプリケーションの特定の側面を改善するためにブロードキャスト/マルチキャストメッセージを使用しますが、ブロードキャスト/マルチキャストメッセージが失敗した場合でも完全に機能します。アプリケーションでのブロードキャストメッセージとマルチキャストメッセージの役割に関係なく、それらを利用するプロトコルの設計者は、ブロードキャストとマルチキャストの特殊な性質のため、プロトコル設計において非常に注意する必要があります。
It is not always possible to implement certain functionality via unicast, but if a protocol designer chooses to rely on broadcast/ multicast, the following should be carefully considered:
ユニキャストを介して特定の機能を実装することが常に可能であるとは限りませんが、プロトコル設計者がブロードキャスト/マルチキャストに依存することを選択した場合、以下を注意深く検討する必要があります。
o IETF-specified protocols, such as mDNS [RFC6762], SHOULD be used if possible as operational support might exist to protect against the leakage of private information. Also, for some protocols, privacy extensions are being specified; these can be used if implemented. For example, for DNS-SD, privacy extensions are documented in [DNSSD-PRIV].
o mDNS [RFC6762]などのIETFで指定されたプロトコルは、運用情報が個人情報の漏洩から保護するために存在する可能性があるため、可能であれば使用する必要があります。また、一部のプロトコルでは、プライバシー拡張が指定されています。これらは実装されていれば使用できます。たとえば、DNS-SDの場合、プライバシー拡張は[DNSSD-PRIV]に文書化されています。
o Using user-specified information inside broadcast/multicast messages SHOULD be avoided, as users will often use personal information or other information that aids attackers, in particular if the user is unaware about how that information is being used.
o ブロードキャスト/マルチキャストメッセージ内でユーザー指定の情報を使用することは避けてください。ユーザーは個人情報や攻撃者を助ける他の情報を使用することが多いため、特にユーザーがその情報の使用方法を知らない場合は特にそうです。
o The use of persistent IDs in messages SHOULD be avoided, as this allows user tracking and correlation, and it potentially has a devastating effect on other privacy-protection mechanisms.
o メッセージでの永続的なIDの使用は避けてください。これにより、ユーザーの追跡と相関が可能になり、他のプライバシー保護メカニズムに壊滅的な影響を与える可能性があります。
o If one must design a new protocol relying on broadcast/multicast and cannot use an IETF-specified protocol, then:
o ブロードキャスト/マルチキャストに依存する新しいプロトコルを設計する必要があり、IETF指定のプロトコルを使用できない場合は、次のようになります。
* the protocol SHOULD be very conservative in how frequently it sends messages as an effort in data minimization,
* プロトコルは、データ最小化の取り組みとしてメッセージを送信する頻度が非常に保守的である必要があります。
* it SHOULD make use of mechanisms implemented in IETF-specified protocols that can be helpful in privacy protection, such as message suppression in mDNS,
* mDNSでのメッセージ抑制など、プライバシー保護に役立つIETF指定のプロトコルで実装されたメカニズムを利用する必要があります。
* it SHOULD be designed in such a way that information sent in broadcast/multicast messages cannot be correlated with information from other protocols using broadcast/multicast, and
* ブロードキャスト/マルチキャストメッセージで送信された情報を、ブロードキャスト/マルチキャストを使用する他のプロトコルからの情報と関連付けることができないように設計する必要があります。
* it SHOULD be possible to let the user configure "safe" 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 Wi-Fi network).
* 可能であれば（SSIDなどに基づいて）ユーザーに「安全な」環境を設定して、情報漏えいのリスク（たとえば、公衆Wi-Fiネットワークではなくホームネットワーク）を最小限に抑えることができるようにする必要があります。
Besides privacy implications, frequent broadcasting also represents a performance problem. In particular, in certain wireless technologies such as 802.11, broadcast and multicast are transmitted at a much lower rate (the lowest common denominator rate) compared to unicast and therefore have a much bigger impact on the overall available airtime [MCAST-CONS]. Further, it will limit the ability for devices
プライバシーへの影響に加えて、頻繁なブロードキャストはパフォーマンスの問題でもあります。特に、802.11などの特定のワイヤレステクノロジーでは、ブロードキャストとマルチキャストはユニキャストと比較してはるかに低いレート（最小公分母レート）で送信されるため、利用可能な全体の通信時間に大きな影響を及ぼします[MCAST-CONS]。さらに、デバイスの機能を制限します
to go to sleep if frequent broadcasts are being sent. A similar problem in respect to Router Advertisements is addressed in [RFC7772]. In that respect, broadcast/multicast can be used for another class of attacks that is not related to privacy. The potential impact on network performance should nevertheless be considered when designing a protocol that makes use of broadcast/ multicast.
頻繁にブロードキャストが送信されている場合はスリープ状態になります。ルータアドバタイズメントに関する同様の問題は、[RFC7772]で対処されています。その点で、ブロードキャスト/マルチキャストは、プライバシーに関連しない別のクラスの攻撃に使用できます。それでも、ブロードキャスト/マルチキャストを利用するプロトコルを設計するときは、ネットワークパフォーマンスへの潜在的な影響を考慮する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document deals with privacy-related considerations for broadcast- and multicast-based protocols. It contains advice for designers of such protocols to minimize the leakage of privacy-sensitive information. The intent of the advice is to make sure that identities will remain anonymous and user tracking will be made difficult.
このドキュメントでは、ブロードキャストおよびマルチキャストベースのプロトコルに関するプライバシー関連の考慮事項について説明します。プライバシーに配慮した情報の漏洩を最小限に抑えるために、そのようなプロトコルの設計者向けのアドバイスが含まれています。アドバイスの目的は、IDが匿名のままであり、ユーザーの追跡が困難になるようにすることです。
To protect multicast traffic, certain applications can make use of existing mechanisms, such as the ones defined in [RFC5374]. Examples of such applications can be found in Appendix A of [RFC5374]. However, given the assumptions about these applications and the required security infrastructure, many applications will not be able to make use of such mechanisms.
マルチキャストトラフィックを保護するために、特定のアプリケーションは、[RFC5374]で定義されているメカニズムなど、既存のメカニズムを利用できます。このようなアプリケーションの例は、[RFC5374]の付録Aにあります。ただし、これらのアプリケーションと必要なセキュリティインフラストラクチャに関する想定を踏まえると、多くのアプリケーションはそのようなメカニズムを利用できません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[DNSSD-PRIV] Huitema, C. and D. Kaiser, "Privacy Extensions for DNS-SD", Work in Progress, draft-ietf-dnssd-privacy-04, April 2018.
[DNSSD-PRIV] Huitema、C。およびD. Kaiser、「DNS-SDのプライバシー拡張」、Work in Progress、draft-ietf-dnssd-privacy-04、2018年4月。
[MCAST-CONS] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", Work in Progress, draft-ietf-mboned-ieee802-mcast-problems-01, February 2018.
[MCAST-CONS] Perkins、C.、McBride、M.、Stanley、D.、Kumari、W.、J。Zuniga、「IEEE 802ワイヤレスメディアを介したマルチキャストの考慮事項」、作業中、draft-ietf-mboned- ieee802-mcast-problems-01、2018年2月。
[RANDOM-ADDR] Huitema, C., "Implications of Randomized Link Layers Addresses for IPv6 Address Assignment", Work in Progress, draft-huitema-6man-random-addresses-03, March 2016.
[RANDOM-ADDR] Huitema、C。、「IPv6アドレス割り当てのランダムリンクレイヤーアドレスの影響」、作業中、draft-huitema-6man-random-addresses-03、2016年3月。
[RFC919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984, <https://www.rfc-editor.org/info/rfc919>.
[RFC919] Mogul、J。、「Broadcasting Internet Datagrams」、STD 5、RFC 919、DOI 10.17487 / RFC0919、1984年10月、<https://www.rfc-editor.org/info/rfc919>。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/info/rfc1812>.
[RFC1812] Baker、F。、編、「IPバージョン4ルーターの要件」、RFC 1812、DOI 10.17487 / RFC1812、1995年6月、<https://www.rfc-editor.org/info/rfc1812>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https://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, <https://www.rfc-editor.org/info/rfc2644>.
[RFC2644] Senie、D。、「Changing the Default for Directed Broadcasts in Routers」、BCP 34、RFC 2644、DOI 10.17487 / RFC2644、1999年8月、<https://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, <https://www.rfc-editor.org/info/rfc3315>.
[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、2003年7月、<https://www.rfc-editor.org/info/rfc3315>。
[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, <https://www.rfc-editor.org/info/rfc3819>.
[RFC3819]カーン、P。、編、ボーマン、C。、フェアハースト、G。、グロスマン、D。、ルートヴィヒ、R。、マハビ、J。、モンテネグロ、G。、タッチ、J.、L。ウッド、「インターネットサブネットワークデザイナーのためのアドバイス」、BCP 89、RFC 3819、DOI 10.17487 / RFC3819、2004年7月、<https://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, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://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, <https://www.rfc-editor.org/info/rfc4795>.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-local Multicast Name Resolution（LLMNR）」、RFC 4795、DOI 10.17487 / RFC4795、2007年1月、<https：//www.rfc- editor.org/info/rfc4795>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：//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, <https://www.rfc-editor.org/info/rfc5374>.
[RFC5374] Weis、B.、Gross、G。、およびD. Ignjatic、「インターネットプロトコルのセキュリティアーキテクチャに対するマルチキャスト拡張」、RFC 5374、DOI 10.17487 / RFC5374、2008年11月、<https：//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, <https://www.rfc-editor.org/info/rfc5771>.
[RFC5771]コットン、M。、ベゴダ、L。、およびD.マイヤー、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 5771、DOI 10.17487 / RFC5771、2010年3月、<https：//www.rfc -editor.org/info/rfc5771>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https://www.rfc-editor.org/info/rfc6762>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F。、およびD. Thaler、「IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：//www.rfc- editor.org/info/rfc7721>。
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, <https://www.rfc-editor.org/info/rfc7772>.
[RFC7772] Yourtchenko、A。およびL. Colitti、「ルーターアドバタイズメントのエネルギー消費の削減」、BCP 202、RFC 7772、DOI 10.17487 / RFC7772、2016年2月、<https://www.rfc-editor.org/info/ rfc7772>。
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, April 2016, <https://www.rfc-editor.org/info/rfc7819>.
[RFC7819] Jiang、S.、Krishnan、S。、およびT. Mrugalski、「DHCPのプライバシーに関する考慮事項」、RFC 7819、DOI 10.17487 / RFC7819、2016年4月、<https://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>.
[RFC8117] Huitema、C.、Thaler、D。、およびR. Winter、「現在のホスト名の実践は有害であると考えられています」、RFC 8117、DOI 10.17487 / RFC8117、2017年3月、<https://www.rfc-editor.org/ info / rfc8117>。
[TRAC2016] Faath, M., Weisshaar, F., and R. Winter, "How Broadcast Data Reveals Your Identity and Social Graph", Wireless Communications and Mobile Computing Conference (IWCMC), International Workshop on TRaffic Analysis and Characterization (TRAC), DOI 10.1109/IWCMC.2016.7577084, September 2016.
[TRAC2016] Faath、M.、Weisshaar、F。、およびR. Winter、「ブロードキャストデータがユーザーのアイデンティティとソーシャルグラフを明らかにする方法」、ワイヤレス通信およびモバイルコンピューティング会議（IWCMC）、トラフィック分析と特性評価に関する国際ワークショップ（TRAC） 、DOI 10.1109 / IWCMC.2016.7577084、2016年9月。
Acknowledgments
謝辞
We would like to thank Eliot Lear, Joe Touch, and Stephane Bortzmeyer for their valuable input to this document.
このドキュメントに対する貴重な情報を提供してくれたEliot Lear、Joe Touch、Stephane Bortzmeyerに感謝します。
This work was partly supported by the European Commission under grant agreement FP7-318627 mPlane. Support does not imply endorsement.
この作業は、助成金契約FP7-318627 mPlaneに基づいて、欧州委員会によって部分的にサポートされました。サポートは保証を意味するものではありません。
Authors' Addresses
著者のアドレス
Rolf Winter University of Applied Sciences Augsburg Augsburg Germany
ロルフウィンター応用科学大学アウクスブルクドイツアウクスブルク
Email: rolf.winter@hs-augsburg.de
Michael Faath Conntac GmbH Augsburg Germany
Michael Faath Conntac GmbHアウクスブルクドイツ
Email: faath@conntac.net
Fabian Weisshaar University of Applied Sciences Augsburg Augsburg Germany
Fabian Weisshaar応用科学大学アウクスブルクドイツアウクスブルク
Email: fabian.weisshaar@hs-augsburg.de