[要約] RFC 8117は、現在のホスト名の慣行が問題を引き起こす可能性があることを指摘している。その目的は、ホスト名の適切な使用方法を提案し、ネットワークのセキュリティと運用の向上を図ることである。
Internet Engineering Task Force (IETF) C. Huitema
Request for Comments: 8117 Private Octopus Inc.
Category: Informational D. Thaler
ISSN: 2070-1721 Microsoft
R. Winter
University of Applied Sciences Augsburg
March 2017
Current Hostname Practice Considered Harmful
有害と見なされる現在のホスト名慣行
Abstract
概要
Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.
コンピュータにホスト名を付け、あるネットワークから別のネットワークに移動するときにホスト名を公開することは、ラペルに名前タグを付けて歩き回るのと同じです。この現在の慣行はあなたのプライバシーを著しく侵害する可能性があり、これらのプライバシーの脅威を軽減するために何かを変更する必要があります。
There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.
さまざまなプロトコルの修正や、ホスト名の公開の回避など、いくつかの可能な対策があります。このドキュメントでは、今日のホスト名を明らかにするプロトコルのいくつかについて説明し、ランダムな値を頻繁に変更することで静的ホスト名を置き換えるという別の可能な対策を示しています。
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 a candidate 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 http://www.rfc-editor.org/info/rfc8117.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8117で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3
3. Partial Identifiers . . . . . . . . . . . . . . . . . . . . . 4
4. Protocols That Leak Hostnames . . . . . . . . . . . . . . . . 5
4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. DNS Address to Name Resolution . . . . . . . . . . . . . 5
4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Link-Local Multicast Name Resolution . . . . . . . . . . 6
4.5. DNS-Based Service Discovery . . . . . . . . . . . . . . . 7
4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7
5. Randomized Hostnames as a Remedy . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Informative References . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
There is a long established practice of giving names to computers. In the Internet protocols, these names are referred to as "hostnames" [RFC7719]. Hostnames are normally used in conjunction with a domain name suffix to build the Fully Qualified Domain Name (FQDN) of a host [RFC1983]. However, it is common practice to use the hostname without further qualification in a variety of applications from file sharing to network management. Hostnames are typically published as part of domain names and can be obtained through a variety of name lookup and discovery protocols.
コンピュータに名前を付ける慣習が長い間あります。インターネットプロトコルでは、これらの名前は「ホスト名」[RFC7719]と呼ばれます。ホスト名は通常、ホストの完全修飾ドメイン名（FQDN）を構築するためにドメイン名サフィックスと組み合わせて使用されます[RFC1983]。ただし、ファイル共有からネットワーク管理までのさまざまなアプリケーションで、資格なしにホスト名を使用するのが一般的です。ホスト名は通常、ドメイン名の一部として公開され、さまざまな名前の検索および検出プロトコルを通じて取得できます。
Hostnames have to be unique within the domain in which they are created and used. They do not have to be globally unique identifiers, but they will always be at least partial identifiers, as discussed in Section 3.
ホスト名は、それらが作成および使用されるドメイン内で一意である必要があります。セクション3で説明するように、グローバルに一意の識別子である必要はありませんが、常に少なくとも部分的な識別子になります。
The disclosure of information through hostnames creates a problem for mobile devices. Adversaries that monitor a remote network such as a Wi-Fi hot spot can obtain the hostname through passive monitoring or active probing of a variety of Internet protocols, such as DHCP or Multicast DNS (mDNS). They can correlate the hostname with various other information extracted from traffic analysis and other information sources, and they can potentially identify the device, device properties, and its user [TRAC2016].
ホスト名による情報の開示は、モバイルデバイスに問題を引き起こします。 Wi-Fiホットスポットなどのリモートネットワークを監視する攻撃者は、DHCPやマルチキャストDNS（mDNS）などのさまざまなインターネットプロトコルのパッシブモニタリングまたはアクティブプローブを通じてホスト名を取得できます。ホスト名をトラフィック分析やその他の情報源から抽出した他のさまざまな情報と関連付けることができ、デバイス、デバイスのプロパティ、およびそのユーザーを特定できる可能性があります[TRAC2016]。
There are many reasons to give names to computers. This is particularly true when computers operate on a network. Operating systems like Microsoft Windows or Unix assume that computers have a "hostname." This enables users and administrators to do things such as ping a computer, add its name to an access control list, remotely mount a computer disk, or connect to the computer through tools such as telnet or remote desktop. Other operating systems maintain multiple hostnames for different purposes, e.g., for use with certain protocols such as mDNS.
コンピュータに名前を付ける理由はたくさんあります。これは、コンピュータがネットワーク上で動作する場合に特に当てはまります。 Microsoft WindowsやUnixなどのオペレーティングシステムは、コンピュータに「ホスト名」があることを前提としています。これにより、ユーザーと管理者は、コンピュータへのping、アクセス制御リストへの名前の追加、コンピュータディスクのリモートマウント、Telnetやリモートデスクトップなどのツールを介したコンピュータへの接続などを実行できます。他のオペレーティングシステムは、mDNSなどの特定のプロトコルで使用するなど、さまざまな目的で複数のホスト名を維持します。
In most consumer networks, naming is pretty much left to the discretion of the user. Some will pick names of planets or stars, others will pick names of fruits or flowers, and still others will pick whatever suits their mood when they unwrap the device. As long as users are careful to not pick a name already in use on the same network, anything goes. Very often, however, the operating system suggests a hostname at the time of installation, which can contain the user name, the login name, and information learned from the device itself such as the brand, model, or maker of the device [TRAC2016].
ほとんどのコンシューマネットワークでは、ネーミングはユーザーの裁量に任されています。惑星や星の名前を選ぶ人もいれば、果物や花の名前を選ぶ人もいれば、デバイスを開封したときに気分に合ったものを選ぶ人もいます。ユーザーが同じネットワークで既に使用されている名前を選択しないように注意している限り、何でも起こります。ただし、多くの場合、オペレーティングシステムはインストール時にホスト名を提案します。これには、ユーザー名、ログイン名、デバイスのブランド、モデル、メーカーなどのデバイス自体から学習した情報を含めることができます[TRAC2016] 。
In large organizations, collisions are more likely and a more structured approach is necessary. In theory, organizations could use multiple DNS subdomains to ease the pressure on uniqueness, but in practice many don't and insist on unique flat names, if only to simplify network management. To ensure unique names, organizations will set naming guidelines and enforce some kind of structured naming. For example, within the Microsoft corporate network, computer names are derived from the login name of the main user, which leads to names like "huitema-test2" for a machine that one of the authors used to test software.
大規模な組織では、衝突が発生する可能性が高く、より構造化されたアプローチが必要です。理論的には、組織は複数のDNSサブドメインを使用して一意性への圧力を緩和できますが、実際には、ネットワーク管理を簡素化するためだけに、多くの人は一意のフラット名を使用せず、主張します。一意の名前を確保するために、組織は命名ガイドラインを設定し、何らかの構造化された命名を実施します。たとえば、マイクロソフトの企業ネットワーク内では、コンピューター名はメインユーザーのログイン名から取得されます。これは、作者の1人がソフトウェアのテストに使用したマシンの「huitema-test2」のような名前になります。
There is less pressure to assign names to small devices including, for example, smart phones, as these devices typically do not enable sharing of their disks or remote login. As a consequence, these devices often have manufacturer-assigned names, which vary from generic names like "Windows Phone" to completely unique names like "BrandX-123456-7890-abcdef" and often contain the name of the device owner, the device's brand name, and often also a hint as to which language the device owner speaks [TRAC2016].
これらのデバイスは通常、ディスクの共有やリモートログインを有効にしないため、スマートフォンなどの小さなデバイスに名前を割り当てる必要はほとんどありません。その結果、これらのデバイスには、「Windows Phone」などの一般的な名前から「BrandX-123456-7890-abcdef」などの完全に一意の名前までさまざまなメーカーが割り当てた名前があり、多くの場合、デバイスの所有者であるデバイスのブランドの名前が含まれます名前、および多くの場合、デバイスの所有者が話す言語に関するヒント[TRAC2016]。
Suppose an adversary wants to track the people connecting to a specific Wi-Fi hot spot, for example, in a railroad station. Assume that the adversary is able to retrieve the hostname used by a specific laptop. That, in itself, might not be enough to identify the laptop's owner. Suppose, however, that the adversary observes that the laptop name is "dthaler-laptop" and that the laptop has established a VPN connection to the Microsoft corporate network. The two pieces of information, put together, firmly point to Dave Thaler, employed by Microsoft. The identification is successful.
敵が、たとえば鉄道駅などの特定のWi-Fiホットスポットに接続している人々を追跡したいとします。攻撃者が特定のラップトップで使用されているホスト名を取得できると仮定します。それだけでは、ラップトップの所有者を特定するのに十分ではない可能性があります。ただし、攻撃者がラップトップ名が「dthaler-laptop」であり、ラップトップがマイクロソフトの企業ネットワークへのVPN接続を確立していることを確認したとします。まとめた2つの情報は、マイクロソフトが採用しているDave Thalerをしっかりと示しています。識別は成功しました。
In the example, we saw a login name inside the hostname, and that certainly helped identification. But generic names like "jupiter" or "rosebud" also provide partial identification, especially if the adversary is capable of maintaining a database recording, among other information, the hostnames of devices used by specific users. Generic names are picked from vocabularies that include thousands of potential choices. Finding the name reduces the scope of the search significantly. Other information such as the visited sites will quickly complement that data and can lead to user identification.
この例では、ホスト名内にログイン名があり、これは確かに識別に役立ちました。ただし、「jupiter」や「rosebud」などの一般的な名前も部分的な識別を提供します。特に、特定のユーザーが使用するデバイスのホスト名などの情報の中で、敵対者がデータベースの記録を維持できる場合は特にそうです。総称名は、何千もの潜在的な選択肢を含む語彙から選ばれます。名前を見つけると、検索範囲が大幅に縮小されます。訪問したサイトなどの他の情報は、そのデータをすばやく補完し、ユーザーの識別につながる可能性があります。
Also, the special circumstances of the network can play a role. Experiments on operational networks such as the IETF meeting network have shown that, with the help of external data such as the publicly available IETF attendees list or other data sources such as Lightweight Directory Access Protocol (LDAP) servers on the network [TRAC2016], the identification of the device owner can become trivial given only partial identifiers in a hostname.
また、ネットワークの特殊な状況が役割を果たす場合もあります。 IETF会議ネットワークなどの運用ネットワークでの実験により、公に利用可能なIETF参加者リストやその他のデータソース（ネットワーク上のライトウェイトディレクトリアクセスプロトコル（LDAP）サーバー[TRAC2016]など）の助けを借りて、ホスト名の一部の識別子のみを指定すると、デバイス所有者の識別は簡単になります。
Unique names assigned by manufacturers do not directly encode a user identifier, but they have the property of being stable and unique to the device in a large context. A unique name like "BrandX-123456-7890-abcdef" allows efficient tracking across multiple domains. In theory, this only allows tracking of the device but not of the user. However, an adversary could correlate the device to the user through other means, for example, the one-time capture of some cleartext traffic. Adversaries could then maintain databases linking a unique hostname to a user identity. This will allow efficient tracking of both the user and the device.
製造元によって割り当てられた一意の名前は、ユーザー識別子を直接エンコードしませんが、大規模なコンテキストでデバイスに対して安定していて一意であるという特性があります。 「BrandX-123456-7890-abcdef」のような一意の名前により、複数のドメインにわたる効率的な追跡が可能になります。理論的には、これはデバイスの追跡のみを許可し、ユーザーの追跡は許可しません。ただし、攻撃者は、他の手段（たとえば、一部のクリアテキストトラフィックの1回限りのキャプチャ）を通じてデバイスをユーザーに関連付ける可能性があります。攻撃者は、一意のホスト名をユーザーIDにリンクするデータベースを維持できます。これにより、ユーザーとデバイスの両方を効率的に追跡できます。
Many IETF protocols can leak the "hostname" of a computer. A non-exhaustive list includes DHCP, DNS address to name resolution, Multicast DNS, Link-local Multicast Name Resolution, and DNS service discovery.
多くのIETFプロトコルは、コンピューターの「ホスト名」をリークする可能性があります。非網羅的なリストには、DHCP、名前解決へのDNSアドレス、マルチキャストDNS、リンクローカルマルチキャスト名前解決、およびDNSサービス検出が含まれます。
Shortly after connecting to a new network, a host can use DHCP [RFC2131] to acquire an IPv4 address and other parameters [RFC2132]. A DHCP query can disclose the "hostname." DHCP traffic is sent to the broadcast address and can be easily monitored, enabling adversaries to discover the hostname associated with a computer visiting a particular network. DHCPv6 [RFC3315] shares similar issues.
新しいネットワークに接続した直後に、ホストはDHCP [RFC2131]を使用してIPv4アドレスとその他のパラメーター[RFC2132]を取得できます。 DHCPクエリは、「ホスト名」を開示できます。 DHCPトラフィックはブロードキャストアドレスに送信され、簡単に監視できるため、攻撃者は特定のネットワークにアクセスするコンピューターに関連付けられているホスト名を発見できます。 DHCPv6 [RFC3315]も同様の問題を共有しています。
The problems with the hostname and FQDN parameters in DHCP are analyzed in [RFC7819] and [RFC7824]. Possible mitigations are described in [RFC7844].
DHCPのホスト名とFQDNパラメータの問題は、[RFC7819]と[RFC7824]で分析されています。可能な緩和策は[RFC7844]で説明されています。
The domain name service design [RFC1035] includes the specification of the special domain "in-addr.arpa" for resolving the name of the computer using a particular IPv4 address, using the PTR format defined in [RFC1033]. A similar domain, "ip6.arpa", is defined in [RFC3596] for finding the name of a computer using a specific IPv6 address.
ドメインネームサービス設計[RFC1035]には、[RFC1033]で定義されているPTR形式を使用して、特定のIPv4アドレスを使用するコンピューターの名前を解決するための特別なドメイン「in-addr.arpa」の仕様が含まれています。同様のドメイン「ip6.arpa」は、特定のIPv6アドレスを使用してコンピュータの名前を見つけるために[RFC3596]で定義されています。
Adversaries who observe a particular address in use on a specific network can try to retrieve the PTR record associated with that address and thus the hostname of the computer, or even the FQDN of that computer. The retrieval may not be useful in many IPv4 networks due to the prevalence of NAT, but it could work in IPv6 networks. Other name lookup mechanisms, such as [RFC4620], share similar issues.
特定のネットワークで使用されている特定のアドレスを観察する攻撃者は、そのアドレスに関連付けられているPTRレコード、つまりコンピューターのホスト名、またはそのコンピューターのFQDNの取得を試みることができます。検索は、NATが普及しているため、多くのIPv4ネットワークでは役に立ちませんが、IPv6ネットワークでは機能します。 [RFC4620]などの他の名前検索メカニズムも同様の問題を共有しています。
Multicast DNS (mDNS) is defined in [RFC6762]. It enables hosts to send DNS queries over multicast and to elicit responses from hosts participating in the service.
マルチキャストDNS（mDNS）は[RFC6762]で定義されています。これにより、ホストはDNSクエリをマルチキャストで送信し、サービスに参加しているホストからの応答を引き出すことができます。
If an adversary suspects that a particular host is present on a network, the adversary can send mDNS requests to find, for example, the A or AAAA records associated with the hostname in the ".local" domain. A positive reply will confirm the presence of the host.
攻撃者が特定のホストがネットワーク上に存在することを疑っている場合、攻撃者はmDNS要求を送信して、たとえば、「。local」ドメイン内のホスト名に関連付けられたAまたはAAAAレコードを見つけることができます。肯定的な応答は、ホストの存在を確認します。
When a new responder starts, it must send a set of multicast queries to verify that the name that it advertises is unique on the network and to populate the caches of other mDNS hosts. Adversaries can monitor this traffic and discover the hostname of computers as they join the monitored network.
新しいレスポンダが起動すると、アドバタイズする一連のマルチキャストクエリを送信して、アドバタイズする名前がネットワーク上で一意であることを確認し、他のmDNSホストのキャッシュに入力する必要があります。攻撃者はこのトラフィックを監視し、監視対象のネットワークに参加するコンピューターのホスト名を発見できます。
mDNS further allows queries to be sent via unicast to port 5353. An adversary might decide to use unicast instead of multicast in order to hide from, e.g., intrusion detection systems.
さらに、mDNSを使用すると、クエリをユニキャスト経由でポート5353に送信できます。攻撃者は、侵入検知システムなどから隠すために、マルチキャストではなくユニキャストを使用することを決定する場合があります。
Link-Local Multicast Name Resolution (LLMNR) is defined in [RFC4795]. The specification did not achieve consensus as an IETF standard, but it is widely deployed. Like mDNS, it enables hosts to send DNS queries over multicast and to elicit responses from computers implementing the LLMNR service.
リンクローカルマルチキャスト名前解決（LLMNR）は[RFC4795]で定義されています。仕様はIETF標準としてコンセンサスを達成しませんでしたが、広く展開されています。 mDNSと同様に、ホストはDNSクエリをマルチキャストで送信し、LLMNRサービスを実装するコンピューターから応答を引き出すことができます。
Like mDNS, LLMNR can be used by adversaries to confirm the presence of a specific host on a network by issuing a multicast request to find the A or AAAA records associated with the hostname in the ".local" domain.
mDNSと同様に、LLMNRは、「。local」ドメインのホスト名に関連付けられたAまたはAAAAレコードを見つけるためにマルチキャスト要求を発行することにより、ネットワーク上の特定のホストの存在を確認するために敵対者が使用できます。
When an LLMNR responder starts, it sends a set of multicast queries to verify that the name that it advertises is unique on the network. Adversaries can monitor this traffic and discover the hostname of computers as they join the monitored network.
LLMNRレスポンダは、起動すると、一連のマルチキャストクエリを送信して、アドバタイズする名前がネットワーク上で一意であることを確認します。攻撃者はこのトラフィックを監視し、監視対象のネットワークに参加するコンピューターのホスト名を発見できます。
DNS-based Service Discovery (DNS-SD) is described in [RFC6763]. It enables participating hosts to retrieve the location of services proposed by other hosts. It can be used with DNS servers or in conjunction with mDNS in a serverless environment.
DNSベースのサービス検出（DNS-SD）は[RFC6763]で説明されています。これにより、参加ホストは他のホストによって提案されたサービスの場所を取得できます。 DNSサーバーで使用したり、サーバーレス環境でmDNSと組み合わせて使用したりできます。
Participating hosts publish a service described by an "instance name", which is typically chosen by the user responsible for the publication. While this is obviously an active disclosure of information, privacy aspects can be mitigated by user control. Services should only be published when deciding to do so, and the information disclosed in the service name should be well under the control of the device's owner.
参加しているホストは、「インスタンス名」で記述されたサービスを公開します。これは通常、公開を担当するユーザーが選択します。これは明らかに情報の積極的な開示ですが、プライバシーの側面はユーザーコントロールによって軽減できます。サービスは、公開することを決定した場合にのみ公開する必要があります。サービス名で開示される情報は、デバイスの所有者の管理下にある必要があります。
In theory, there should not be any privacy issue, but in practice the publication of a service also forces the publication of the hostname due to a chain of dependencies. The service name is used to publish a PTR record announcing the service. The PTR record typically points to the service name in the local domain. The service names, in turn, are used to publish TXT records describing service parameters and SRV records describing the service location.
理論的には、プライバシーの問題はないはずですが、実際には、サービスの公開は、依存関係の連鎖のためにホスト名の公開も強制します。サービス名は、サービスを通知するPTRレコードを公開するために使用されます。 PTRレコードは通常、ローカルドメインのサービス名を指します。次に、サービス名は、サービスパラメータを説明するTXTレコードとサービスの場所を説明するSRVレコードを公開するために使用されます。
SRV records are described in [RFC2782]. Each record contains four parameters: priority, weight, port number, and hostname. While the service name published in the PTR record is chosen by the user, the "hostname" in the SRV record is indeed the hostname of the device.
SRVレコードは[RFC2782]で説明されています。各レコードには、優先度、重み、ポート番号、ホスト名の4つのパラメーターが含まれています。 PTRレコードで公開されているサービス名はユーザーが選択しますが、SRVレコードの「ホスト名」は実際にデバイスのホスト名です。
Adversaries can monitor the mDNS traffic associated with DNS-SD and retrieve the hostname of computers advertising any service with DNS-SD.
攻撃者は、DNS-SDに関連付けられたmDNSトラフィックを監視し、DNS-SDでサービスを宣伝しているコンピューターのホスト名を取得できます。
Amongst other things, NetBIOS-over-TCP [RFC1002] implements a name registration and resolution mechanism called the NetBIOS Name Service. In practice, NetBIOS resource names are often based on hostnames.
特に、NetBIOS-over-TCP [RFC1002]は、NetBIOSネームサービスと呼ばれる名前の登録と解決のメカニズムを実装しています。実際には、NetBIOSリソース名は多くの場合、ホスト名に基づいています。
NetBIOS allows an application to register resource names and to resolve such names to IP addresses. In environments without a NetBIOS Name Server, the protocol makes extensive use of broadcasts from which resource names can be easily extracted. NetBIOS also allows querying for the names registered by a node directly (node status).
NetBIOSを使用すると、アプリケーションはリソース名を登録し、そのような名前をIPアドレスに解決できます。 NetBIOSネームサーバーのない環境では、プロトコルはブロードキャストを広範囲に使用して、リソース名を簡単に抽出できます。 NetBIOSでは、ノードによって直接登録された名前のクエリも可能です（ノードステータス）。
There are several ways to remedy the hostname practices. We could instruct people to just turn off any protocol that leaks hostnames, at least when they visit some "insecure" place. We could also examine each particular standard that publishes hostnames and somehow fix the corresponding protocols. Or, we could attempt to revise the way devices manage the hostname parameter.
ホスト名の慣行を改善するにはいくつかの方法があります。少なくとも「安全でない」場所を訪れたときは、ホスト名をリークするプロトコルをオフにするように指示することができます。ホスト名を公開する特定の標準をそれぞれ調べて、対応するプロトコルを修正することもできます。または、デバイスがホスト名パラメーターを管理する方法を修正することもできます。
There is a lot of merit in turning off unneeded protocols when visiting insecure places. This amounts to attack-surface reduction and is clearly beneficial -- this is an advantage of the stealth mode defined in [RFC7288]. However, there are two issues with this advice. First, it relies on recognizing which networks are secure or insecure. This is hard to automate, but relying on end-user judgment may not always provide good results. Second, some protocols such as DHCP cannot be turned off without losing connectivity, which limits the value of this option. Also, the services that rely on protocols that leak hostnames such as mDNS will not be available when switched off. In addition, not always are hostname-leaking protocols well-known, as they might be proprietary and come with an installed application instead of being provided by the operating system.
安全でない場所にアクセスするときに不要なプロトコルをオフにすることには多くのメリットがあります。これは攻撃面の削減に相当し、明らかに有益です。これは、[RFC7288]で定義されているステルスモードの利点です。ただし、このアドバイスには2つの問題があります。 1つ目は、どのネットワークが安全であるか、安全でないかを認識することです。これを自動化することは困難ですが、エンドユーザーの判断に依存しても、常に良い結果が得られるとは限りません。次に、DHCPなどの一部のプロトコルは、接続を失うことなくオフにすることができないため、このオプションの値が制限されます。また、mDNSなどのホスト名をリークするプロトコルに依存するサービスは、オフにすると使用できなくなります。さらに、独自仕様で、オペレーティングシステムから提供されるのではなく、アプリケーションがインストールされている場合があるため、ホスト名漏えいプロトコルが必ずしもよく知られているとは限りません。
It may be possible in many cases to examine a protocol and prevent it from leaking hostnames. This is, for example, what is attempted for DHCP in [RFC7844]. However, it is unclear that we can identify, revisit, and fix all the protocols that publish hostnames. In particular, this is impossible for proprietary protocols.
多くの場合、プロトコルを調べて、ホスト名の漏洩を防ぐことが可能です。これは、たとえば、[RFC7844]でDHCPに対して試みられていることです。ただし、ホスト名を公開するすべてのプロトコルを識別、再検討、修正できるかどうかは不明です。特に、これは独自のプロトコルでは不可能です。
We may be able to mitigate most of the effects of hostname leakage by revisiting the way platforms handle hostnames. In a way, this is similar to the approach of Media Access Control (MAC) address randomization described in [RFC7844]. Let's assume that the operating system, at the time of connecting to a new network, picks a random hostname and starts publicizing that random name in protocols such as DHCP or mDNS, instead of the static value. This will render monitoring and identification of users by adversaries much more difficult without preventing protocols such as DNS-SD from operating as expected. This, of course, has implications on the applications making use of such protocols, e.g., when the hostname is being displayed to users of the application. They will not as easily be able to identify, e.g., network shares or services based on the hostname carried in the underlying protocols. Also, the generation of new hostnames should be synchronized with the change of other tokens used in network protocols such as the MAC or IP address to prevent correlation of this information. For example, if the IP address changes but the hostname stays the same, the new IP address can be correlated to belong to the same device based on a leaked hostname.
プラットフォームがホスト名を処理する方法を再検討することにより、ホスト名漏洩の影響のほとんどを軽減できる可能性があります。ある意味で、これは[RFC7844]で説明されているMedia Access Control（MAC）アドレスのランダム化のアプローチに似ています。オペレーティングシステムが新しいネットワークに接続するときに、ランダムなホスト名を選択し、静的な値ではなく、DHCPやmDNSなどのプロトコルでそのランダムな名前の公開を開始するとします。これにより、DNS-SDなどのプロトコルが期待どおりに動作することを妨げることなく、敵対者によるユーザーの監視と識別がさらに困難になります。もちろん、これは、たとえばホスト名がアプリケーションのユーザーに表示されているときなど、そのようなプロトコルを使用するアプリケーションに影響を与えます。たとえば、基盤となるプロトコルで伝送されるホスト名に基づいて、ネットワーク共有やサービスなどを簡単に特定することはできません。また、新しいホスト名の生成は、MACまたはIPアドレスなどのネットワークプロトコルで使用される他のトークンの変更と同期して、この情報の相関を防ぐ必要があります。たとえば、IPアドレスが変更されてもホスト名が同じである場合、新しいIPアドレスは、リークされたホスト名に基づいて同じデバイスに属するように関連付けることができます。
Some operating systems, including Windows, support "per network" hostnames, but some other operating systems only support "global" hostnames. In that case, changing the hostname may be difficult if the host is multihomed, as the same name will be used on several networks. Other operating systems already use potentially different hostnames for different purposes, which might be a good model to combine both static hostnames and randomized hostnames based on their potential use and threat to a user's privacy.
Windowsを含む一部のオペレーティングシステムは「ネットワークごとの」ホスト名をサポートしていますが、他の一部のオペレーティングシステムは「グローバル」ホスト名のみをサポートしています。その場合、ホストがマルチホームである場合、同じ名前が複数のネットワークで使用されるため、ホスト名の変更が難しい場合があります。他のオペレーティングシステムは、さまざまな目的で潜在的に異なるホスト名をすでに使用しています。これは、潜在的な使用とユーザーのプライバシーに対する脅威に基づいて、静的ホスト名とランダム化されたホスト名の両方を組み合わせる優れたモデルとなる場合があります。
Obviously, further studies are required before the idea of randomized hostnames can be implemented.
明らかに、ランダム化されたホスト名のアイデアを実装する前に、さらなる調査が必要です。
This document does not introduce any new protocol. It does point to potential privacy issues in a set of existing protocols.
このドキュメントでは、新しいプロトコルを紹介していません。既存のプロトコルのセットに潜在的なプライバシーの問題があることを示しています。
There are obvious privacy gains to changing to randomized hostnames and also to changing these names frequently. However, wide deployment might affect security functions or current practices. For example, incident response using hostnames to track the source of traffic might be affected. It is common practice to include hostnames and reverse lookup information at various times during an investigation.
ランダム化されたホスト名に変更したり、これらの名前を頻繁に変更したりすると、プライバシーが明らかに向上します。ただし、幅広い展開は、セキュリティ機能または現在の慣行に影響を与える可能性があります。たとえば、トラフィックのソースを追跡するためにホスト名を使用するインシデントレスポンスが影響を受ける可能性があります。調査中のさまざまなタイミングでホスト名と逆引き情報を含めることは一般的な方法です。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC1002] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications", STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, <http://www.rfc-editor.org/info/rfc1002>.
[RFC1002]国防高等研究計画局、インターネット活動委員会、およびエンドツーエンドサービスタスクフォースのNetBIOSワーキンググループ、「TCP / UDPトランスポート上のNetBIOSサービスのプロトコル標準：詳細な仕様」、STD 19、RFC 1002、DOI 10.17487 / RFC1002、1987年3月、<http://www.rfc-editor.org/info/rfc1002>。
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, DOI 10.17487/RFC1033, November 1987, <http://www.rfc-editor.org/info/rfc1033>.
[RFC1033] Lottor、M。、「ドメイン管理者操作ガイド」、RFC 1033、DOI 10.17487 / RFC1033、1987年11月、<http://www.rfc-editor.org/info/rfc1033>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, RFC 1983, DOI 10.17487/RFC1983, August 1996, <http://www.rfc-editor.org/info/rfc1983>.
[RFC1983] Malkin、G.、Ed。、「Internet Users 'Glossary」、FY18、RFC 1983、DOI 10.17487 / RFC1983、1996年8月、<http://www.rfc-editor.org/info/rfc1983>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<http://www.rfc-editor.org/info/rfc2132>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<http：// www.rfc-editor.org/info/rfc2782>。
[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>.
[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月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、DOI 10.17487 / RFC3596、2003年10月、<http：// www .rfc-editor.org / info / rfc3596>。
[RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006, <http://www.rfc-editor.org/info/rfc4620>.
[RFC4620]クロフォードM.およびB.ハーバーマン編、「IPv6ノード情報クエリ」、RFC 4620、DOI 10.17487 / RFC4620、2006年8月、<http://www.rfc-editor.org/info/rfc4620> 。
[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>.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-local Multicast Name Resolution（LLMNR）」、RFC 4795、DOI 10.17487 / RFC4795、2007年1月、<http：//www.rfc- editor.org/info/rfc4795>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<http://www.rfc-editor.org/info/rfc6762>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNS-Based Service Discovery」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<http://www.rfc-editor.org/info/rfc6763>。
[RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI 10.17487/RFC7288, June 2014, <http://www.rfc-editor.org/info/rfc7288>.
[RFC7288] Thaler、D。、「Reflections on Host Firewalls」、RFC 7288、DOI 10.17487 / RFC7288、2014年6月、<http://www.rfc-editor.org/info/rfc7288>。
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719] Hoffman、P.、Sullivan、A。、およびK. Fujiwara、「DNS用語」、RFC 7719、DOI 10.17487 / RFC7719、2015年12月、<http://www.rfc-editor.org/info/rfc7719 >。
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, April 2016, <http://www.rfc-editor.org/info/rfc7819>.
[RFC7819] Jiang、S.、Krishnan、S。、およびT. Mrugalski、「DHCPのプライバシーに関する考慮事項」、RFC 7819、DOI 10.17487 / RFC7819、2016年4月、<http://www.rfc-editor.org/info / rfc7819>。
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, <http://www.rfc-editor.org/info/rfc7824>.
[RFC7824]クリシュナン、S.、Mrugalski、T。、およびS. Jiang、「DHCPv6のプライバシーに関する考慮事項」、RFC 7824、DOI 10.17487 / RFC7824、2016年5月、<http://www.rfc-editor.org/info / rfc7824>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T。、およびS. Krishnan、「DHCPクライアントの匿名プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<http://www.rfc-editor.org/ info / rfc7844>。
[TRAC2016] Faath, M., Winter, R., and F. Weisshaar, "How Broadcast Data Reveals Your Identity and Social Graph", IEEE, Wireless Communications and Mobile Computing Conference (IWCMC), 2016 International, DOI 10.1109/IWCMC.2016.7577084, September 2016.
[TRAC2016] Faath、M.、Winter、R。、およびF. Weisshaar、「ブロードキャストデータがアイデンティティとソーシャルグラフを明らかにする方法」、IEEE、ワイヤレス通信およびモバイルコンピューティング会議（IWCMC）、2016 International、DOI 10.1109 / IWCMC。 2016.7577084、2016年9月。
Acknowledgments
謝辞
Thanks to the members of the INTAREA Working Group for discussions and reviews.
議論とレビューをしてくれたINTAREAワーキンググループのメンバーに感謝します。
Authors' Addresses
著者のアドレス
Christian Huitema Private Octopus Inc. Friday Harbor, WA 98250 United States of America
Christian Huitema Private Octopus Inc.フライデーハーバー、ワシントン州98250アメリカ合衆国
Email: huitema@huitema.net
Dave Thaler Microsoft Redmond, WA 98052 United States of America
デイブターラーマイクロソフトレドモンド、ワシントン州98052アメリカ合衆国
Email: dthaler@microsoft.com
Rolf Winter University of Applied Sciences Augsburg Augsburg DE
ロルフウィンター応用科学大学アウクスブルクアウクスブルクDE
Email: rolf.winter@hs-augsburg.de