[要約] RFC 7754は、インターネットサービスのブロッキングとフィルタリングに関する技術的な考慮事項をまとめたものです。その目的は、インターネットサービスプロバイダやネットワーク管理者がブロッキングやフィルタリングを実施する際のガイドラインを提供することです。
Internet Architecture Board (IAB) R. Barnes
Request for Comments: 7754 A. Cooper
Category: Informational O. Kolkman
ISSN: 2070-1721 D. Thaler
E. Nordmark
March 2016
Technical Considerations for Internet Service Blocking and Filtering
インターネットサービスのブロックとフィルタリングに関する技術的な考慮事項
Abstract
概要
The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.
インターネットは、オープンな通信媒体として構築されています。この開放性はインターネットイノベーションの重要な基盤の1つですが、特定の関係者にとって望ましくないと見なされる可能性のある通信も可能になります。したがって、インターネットが成長するにつれて、虐待的または不快なコミュニケーションの範囲と影響を制限するメカニズムも発達します。最近、このような通信を積極的に防止する「ブロック」と「フィルタリング」がますます重要視されています。このドキュメントでは、インターネットの全体的なインターネットアーキテクチャとの整合性の観点から、インターネットのブロックとフィルタリングに対するいくつかの技術的なアプローチを検討します。そうすることが可能な場合、インターネットアーキテクチャと最も整合性のあるブロッキングとフィルタリングのアプローチは、潜在的に望ましくないサービスについてエンドポイントに通知することです。これにより、コミュニカントは乱用または不快な通信に従事することを回避できます。特定のフィルタリングとブロックのアプローチが第三者に意図しない結果を引き起こす可能性があることを観察し、さまざまなアプローチの有効性の限界について議論します。
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 Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション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/rfc7754.
このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7754で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Filtering Examples . . . . . . . . . . . . . . . . . . . . . 5
3. Characteristics of Blocking Systems . . . . . . . . . . . . . 7
3.1. The Party Who Sets Blocking Policies . . . . . . . . . . 8
3.2. Purposes of Blocking . . . . . . . . . . . . . . . . . . 8
3.2.1. Blacklist vs. Whitelist Model . . . . . . . . . . . . 9
3.3. Intended Targets of Blocking . . . . . . . . . . . . . . 9
3.4. Components Used for Blocking . . . . . . . . . . . . . . 10
4. Evaluation of Blocking Design Patterns . . . . . . . . . . . 11
4.1. Criteria for Evaluation . . . . . . . . . . . . . . . . . 11
4.1.1. Scope: What set of hosts and users are affected? . . 12
4.1.2. Granularity: How specific is the blocking? Will
blocking one service also block others? . . . . . . . 12
4.1.3. Efficacy: How easy is it for a resource or service to
avoid being blocked? . . . . . . . . . . . . . . . . 13
4.1.4. Security: How does the blocking impact existing trust
infrastructures? . . . . . . . . . . . . . . . . . . 14
4.2. Network-Based Blocking . . . . . . . . . . . . . . . . . 15
4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Granularity . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. Efficacy and Security . . . . . . . . . . . . . . . . 17
4.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Rendezvous-Based Blocking . . . . . . . . . . . . . . . . 20
4.3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.2. Granularity . . . . . . . . . . . . . . . . . . . . . 21
4.3.3. Efficacy . . . . . . . . . . . . . . . . . . . . . . 21
4.3.4. Security and Other Implications . . . . . . . . . . . 22
4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 22
4.3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Endpoint-Based Blocking . . . . . . . . . . . . . . . . . 24
4.4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.2. Granularity . . . . . . . . . . . . . . . . . . . . . 24
4.4.3. Efficacy . . . . . . . . . . . . . . . . . . . . . . 25
4.4.4. Security . . . . . . . . . . . . . . . . . . . . . . 25
4.4.5. Server Endpoints . . . . . . . . . . . . . . . . . . 25
4.4.6. Summary . . . . . . . . . . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Informative References . . . . . . . . . . . . . . . . . . . 28
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
The original design goal of the Internet was to enable communications between hosts. As this goal was met and people started using the Internet to communicate, however, it became apparent that some hosts were engaging in communications that were viewed as undesirable by certain parties. The most famous early example of undesirable communications was the Morris worm [Morris], which used the Internet to infect many hosts in 1988. As the Internet has evolved into a rich communications medium, so too have mechanisms to restrict communications viewed as undesirable, ranging from acceptable use policies enforced through informal channels to technical blocking mechanisms.
インターネットの当初の設計目標は、ホスト間の通信を可能にすることでした。しかし、この目標が達成され、人々がインターネットを使用して通信を始めたとき、一部のホストが望ましくないと見なしている通信に従事しているホストがいることが明らかになりました。望ましくない通信の最も有名な初期の例は、1988年にインターネットを使用して多くのホストに感染したMorrisワーム[Morris]でした。インターネットが豊富な通信媒体に進化するにつれて、望ましくないと見なされる通信を制限するメカニズムも広がっています。非公式なチャネルを通じて実施される利用規定から技術的な遮断メカニズムまで。
Efforts to restrict or deny access to Internet resources and services have evolved over time. As noted in [RFC4084], some Internet service providers perform filtering to restrict which applications their customers may use and which traffic they allow on their networks. These restrictions are often imposed with customer consent, where customers may be enterprises or individuals. However, governments, service providers, and enterprises are increasingly seeking to block or filter access to certain content, traffic, or services without the knowledge or agreement of affected users. Where these organizations do not directly control networks themselves, they commonly aim to make use of intermediary systems to implement the blocking or filtering.
インターネットのリソースとサービスへのアクセスを制限または拒否する取り組みは、時間とともに発展してきました。 [RFC4084]で述べられているように、一部のインターネットサービスプロバイダーはフィルタリングを実行して、顧客が使用するアプリケーションとネットワークで許可するトラフィックを制限しています。これらの制限は、顧客が企業または個人である場合がある顧客の同意によって課せられることがよくあります。ただし、政府、サービスプロバイダー、および企業は、影響を受けるユーザーの知識や合意なしに、特定のコンテンツ、トラフィック、またはサービスへのアクセスをブロックまたはフィルタリングすることをますます求めています。これらの組織がネットワーク自体を直接制御しない場合、通常、中間システムを利用してブロッキングまたはフィルタリングを実装することを目的としています。
While blocking and filtering remain highly contentious in many cases, the desire to restrict communications or access to content will likely continue to exist.
多くの場合、ブロックとフィルタリングは非常に論争の的となっていますが、通信やコンテンツへのアクセスを制限したいという欲求は引き続き存在するでしょう。
The difference between "blocking" and "filtering" is a matter of scale and perspective. "Blocking" often refers to preventing access to resources in the aggregate, while "filtering" refers to preventing access to specific resources within an aggregate. Both blocking and filtering can be implemented at the level of "services" (web hosting or video streaming, for example) or at the level of particular "content." For the analysis presented in this document, the distinction between blocking and filtering does not create meaningfully different conclusions. Hence, in the remainder of this document, we will treat the terms as being generally equivalent and applicable to restrictions on both content and services.
「ブロッキング」と「フィルタリング」の違いは、規模と視点の問題です。 「ブロッキング」は多くの場合、アグリゲート内のリソースへのアクセスを防ぐことを指し、「フィルタリング」はアグリゲート内の特定のリソースへのアクセスを防ぐことを指します。ブロッキングとフィルタリングの両方を「サービス」のレベル（たとえば、Webホスティングやビデオストリーミング）または特定の「コンテンツ」のレベルで実装できます。このドキュメントで提示されている分析では、ブロッキングとフィルタリングの違いは意味のある異なる結論を生み出しません。したがって、このドキュメントの残りの部分では、これらの用語は一般に同等であり、コンテンツとサービスの両方の制限に適用できるものとして扱います。
This document aims to clarify the technical implications and trade-offs of various blocking strategies and to identify the potential for different strategies to potentially cause harmful side effects ("collateral damage") for Internet users and the overall Internet architecture. This analysis is limited to technical blocking mechanisms. The scope of the analyzed blocking is limited to intentional blocking, not accidental blocking due to misconfiguration or as an unintentional side effect of something else.
このドキュメントは、さまざまなブロック戦略の技術的な影響とトレードオフを明確にし、さまざまな戦略がインターネットユーザーとインターネットアーキテクチャ全体に有害な副作用（「副次的被害」）を引き起こす可能性を特定することを目的としています。この分析は、技術的な遮断メカニズムに限定されています。分析されたブロッキングの範囲は、意図的なブロッキングに限定されており、構成ミスによる偶発的なブロッキングや、他の何かの意図しない副作用としてではありません。
Filtering may be considered legal, illegal, ethical, or unethical in different places, at different times, and by different parties. This document is intended for those who are conducting filtering or are considering conducting filtering and want to understand the implications of their decisions with respect to the Internet architecture and the trade-offs that come with each type of filtering strategy. This document does not present formulas on how to make those trade-offs; it is likely that filtering decisions require knowledge of context-specific details. Whether particular forms of filtering are lawful in particular jurisdictions raises complicated legal questions that are outside the scope of this document. For similar reasons, questions about the ethics of particular forms of filtering are also out of scope.
フィルタリングは、さまざまな場所で、さまざまなタイミングで、さまざまな関係者によって、合法的、違法、倫理的、または非倫理的と見なされる場合があります。このドキュメントは、フィルタリングを実行している、またはフィルタリングの実行を検討していて、インターネットアーキテクチャに関する決定の影響と、各タイプのフィルタリング戦略に伴うトレードオフを理解したい人を対象としています。このドキュメントでは、これらのトレードオフを行う方法についての公式は示していません。フィルタリングの決定には、コンテキスト固有の詳細の知識が必要になる可能性があります。特定の管轄区域で特定の形式のフィルタリングが合法かどうかは、このドキュメントの範囲外である複雑な法的問題を提起します。同様の理由で、特定の形式のフィルタリングの倫理に関する質問も範囲外です。
Blocking systems have evolved alongside the Internet technologies they seek to restrict. Looking back at the history of the Internet, there have been several such systems deployed by different parties and for different purposes.
ブロッキングシステムは、制限しようとしているインターネット技術とともに進化してきました。インターネットの歴史を振り返ってみると、さまざまな関係者によってさまざまな目的で導入されたこのようなシステムがいくつかあります。
Firewalls: Firewalls of various sorts are very commonly employed at many points in today's Internet [RFC2979]. They can be deployed either on end hosts (under user or administrator control) or in the network, typically at network boundaries. While the Internet Security Glossary [RFC4949] contains an extended definition of a firewall, informally, most people would tend to think of a firewall as simply "something that blocks unwanted traffic" (see [RFC4948] for a discussion on many types of unwanted traffic). While there are many sorts of firewalls, there are several specific types of firewall functionality worth noting.
ファイアウォール：さまざまな種類のファイアウォールが、今日のインターネットの多くのポイントで非常に一般的に採用されています[RFC2979]。これらは、エンドユーザー（ユーザーまたは管理者の制御下）またはネットワーク（通常はネットワーク境界）に展開できます。インターネットセキュリティ用語集[RFC4949]にはファイアウォールの拡張定義が含まれていますが、非公式に言えば、ほとんどの人はファイアウォールを単に「不要なトラフィックをブロックするもの」と考える傾向があります（多くの種類の不要なトラフィックの説明については[RFC4948]を参照してください） ）。ファイアウォールにはさまざまな種類がありますが、注目に値するいくつかの特定の種類のファイアウォール機能があります。
o Stateless Packet Filtering: Stateless packet filters block according to content-neutral rules, e.g., blocking all inbound connections or outbound connections on certain ports, protocols, or network-layer addresses. For example, blocking outbound connections to port 25.
o ステートレスパケットフィルタリング：ステートレスパケットフィルターは、コンテンツ中立のルールに従ってブロックします。たとえば、特定のポート、プロトコル、またはネットワーク層アドレスでのすべてのインバウンド接続またはアウトバウンド接続をブロックします。たとえば、ポート25への送信接続をブロックします。
o Stateful Packet Filtering: More advanced configurations require keeping state used to enforce flow-based policies, e.g., blocking inbound traffic for flows that have not been established.
o ステートフルパケットフィルタリング：より高度な構成では、フローベースのポリシーを適用するために使用される状態を維持する必要があります。たとえば、確立されていないフローの受信トラフィックをブロックします。
o Deep Packet Inspection: Yet more advanced configurations perform deep packet inspection and filter or block based on the content carried. Many firewalls include web filtering capabilities (see below).
o ディープパケットインスペクション：さらに高度な構成では、ディープパケットインスペクションを実行し、伝送されたコンテンツに基づいてフィルターまたはブロックします。多くのファイアウォールには、Webフィルタリング機能が含まれています（以下を参照）。
Web Filtering: HTTP and HTTPS are common targets for blocking and filtering, typically targeted at specific URIs. Some enterprises use HTTP blocking to block non-work-appropriate web sites, and several nations require HTTP and HTTPS filtering by their ISPs in order to block content deemed illegal. HTTPS is a challenge for these systems, because the URI in an HTTPS request is carried inside the encrypted channel. To block access to content made accessible via HTTPS, filtering systems thus must either block based on network- and transport-layer headers (IP address and/or port), or else obtain a trust anchor certificate that is trusted by endpoints (and thus act as a man in the middle). These filtering systems often take the form of "portals" or "enterprise proxies" presenting their own, dynamically generated HTTPS certificates. (See further discussion in Section 5.)
Webフィルタリング：HTTPとHTTPSは、ブロックとフィルタリングの一般的なターゲットであり、通常は特定のURIをターゲットとしています。一部の企業はHTTPブロッキングを使用して、仕事に適さないWebサイトをブロックします。いくつかの国では、違法と見なされるコンテンツをブロックするために、ISPによるHTTPおよびHTTPSフィルタリングが必要です。 HTTPS要求のURIは暗号化されたチャネル内で運ばれるため、HTTPSはこれらのシステムの課題です。 HTTPSを介してアクセス可能にされたコンテンツへのアクセスをブロックするには、フィルタリングシステムがネットワーク層およびトランスポート層のヘッダー（IPアドレスまたはポート、あるいはその両方）に基づいてブロックするか、エンドポイントによって信頼されるトラストアンカー証明書を取得する必要があります真ん中の男として）。これらのフィルタリングシステムは、動的に生成された独自のHTTPS証明書を提示する「ポータル」または「エンタープライズプロキシ」の形式を取ることがよくあります。 （セクション5の詳細な説明を参照してください。）
Spam Filtering: Spam filtering is one of the oldest forms of content filtering. Spam filters evaluate messages based on a variety of criteria and information sources to decide whether a given message is spam. For example, DNS Blacklists use the reverse DNS to flag whether an IP address is a known spam source [RFC5782]. Spam filters can be installed on user devices (e.g., in a mail client), operated by a mail domain on behalf of users, or outsourced to a third party that acts as an intermediate MX proxy.
スパムフィルタリング：スパムフィルタリングは、コンテンツフィルタリングの最も古い形式の1つです。スパムフィルターは、さまざまな基準と情報ソースに基づいてメッセージを評価し、特定のメッセージがスパムかどうかを判断します。たとえば、DNSブラックリストは逆DNSを使用して、IPアドレスが既知のスパム送信元であるかどうかにフラグを立てます[RFC5782]。スパムフィルターは、ユーザーデバイス（メールクライアントなど）にインストールしたり、ユーザーに代わってメールドメインで操作したり、中間MXプロキシとして機能するサードパーティにアウトソーシングしたりできます。
Domain Name Seizure: A number of approaches are used to block or modify resolution of a domain name. One approach is to make use of ICANN's Uniform Dispute Resolution Policy (URDP) for the purposes of dealing with fraudulent use of a name. Other authorities may require that domains be blocked within their jurisdictions. Substantial research has been performed on the value and efficacy of such seizures [Takedown08] [BlackLists14].
ドメイン名の差し押さえ：ドメイン名の解決をブロックまたは変更するには、いくつかのアプローチが使用されます。 1つのアプローチは、名前の不正使用に対処する目的でICANNの統一紛争解決ポリシー（URDP）を利用することです。他の当局は、管轄区域内でドメインをブロックすることを要求する場合があります。このような発作の価値と有効性については、かなりの研究が行われています[Takedown08] [BlackLists14]。
The precise method of how domain names are seized will vary from place to place. One approach in use is for queries to be redirected to resolve to IP addresses of the authority that hosts information about the seizure. The effectiveness of domain seizures will similarly vary based on the method. In some cases, the person whose name was seized will simply use a new name. In other cases, the block may only be effective within a region or when specific name service infrastructure is used.
ドメイン名が押収される方法の正確な方法は場所によって異なります。使用されているアプローチの1つは、クエリをリダイレクトして、押収に関する情報をホストする機関のIPアドレスに解決することです。ドメイン差し押さえの有効性は、メソッドに基づいて同様に異なります。場合によっては、名前が押収された人は単に新しい名前を使用します。他の場合では、ブロックはリージョン内または特定のネームサービスインフラストラクチャが使用されている場合にのみ有効になる場合があります。
Seizures can also have overbroad effects, since access to content is blocked not only within the jurisdiction of the seizure, but globally, even when it may be affirmatively legal elsewhere [RojaDirecta]. When domain redirection is effected via redirections at intermediate resolvers rather than at authoritative servers, it directly contradicts end-to-end assumptions in the DNS security architecture [RFC4033], potentially causing validation failures by validating end-nodes.
コンテンツへのアクセスは、差し押さえの管轄区域内だけでなく、グローバルに、他の場所で肯定的に合法である場合でもブロックされるため、差し押さえは広範な影響を与える可能性もあります[RojaDirecta]。権限のあるサーバーではなく中間リゾルバーでリダイレクトを介してドメインのリダイレクトが影響を受ける場合、DNSセキュリティアーキテクチャ[RFC4033]のエンドツーエンドの仮定に直接矛盾し、エンドノードを検証することで検証エラーを引き起こす可能性があります。
Safe Browsing: Modern web browsers provide some measures to prevent users from accessing malicious web sites. For instance, before loading a URI, current versions of Google Chrome and Firefox use the Google Safe Browsing service to determine whether or not a given URI is safe to load [SafeBrowsing]. The DNS can also be used to store third party information that mark domains as safe or unsafe [RFC5782].
セーフブラウジング：最新のWebブラウザーは、ユーザーが悪意のあるWebサイトにアクセスするのを防ぐための手段を提供します。たとえば、URIをロードする前に、Google ChromeとFirefoxの現在のバージョンはGoogleセーフブラウジングサービスを使用して、特定のURIが安全にロードできるかどうかを判断します[SafeBrowsing]。 DNSは、ドメインを安全または危険としてマークするサードパーティの情報を保存するためにも使用できます[RFC5782]。
Manipulation of routing and addressing data: Governments have recently intervened in the management of IP addressing and routing information in order to maintain control over a specific set of DNS servers. As part of an internationally coordinated response to the DNSChanger malware, a Dutch court ordered the RIPE NCC to freeze the accounts of several resource holders as a means to limit the resource holders' ability to use certain address blocks [GhostClickRIPE] (also see Section 4.3). These actions have led to concerns that the number resource certification system and related secure routing technologies developed by the IETF's SIDR working group might be subject to government manipulation as well [RFC6480], potentially for the purpose of denying targeted networks access to the Internet.
ルーティングとアドレッシングデータの操作：政府は最近、特定のDNSサーバーセットの制御を維持するために、IPアドレッシングとルーティング情報の管理に介入しています。 DNSChangerマルウェアに対する国際的に調整された対応の一環として、オランダの裁判所は、RIPE NCCに、特定のアドレスブロックを使用するリソースホルダーの機能を制限する手段として、いくつかのリソースホルダーのアカウントを凍結するように命じました[GhostClickRIPE]（セクション4.3も参照） ）。これらのアクションは、IETFのSIDRワーキンググループによって開発されたリソース認証システムと関連する安全なルーティングテクノロジーが、インターネットへのターゲットネットワークアクセスを拒否する目的で、政府の操作[RFC6480]の対象となる可能性があるという懸念につながりました。
Ingress filtering: Network service providers use ingress filtering [RFC2827] [RFC3704] as a means to prevent source address spoofing which is used as a part of other attacks.
入口フィルタリング：ネットワークサービスプロバイダーは、他の攻撃の一部として使用される送信元アドレスのスプーフィングを防止する手段として、入口フィルタリング[RFC2827] [RFC3704]を使用します。
Data loss prevention (DLP): Enterprise and other networks are concerned with potential leaking of confidential information, whether accidental or intentional. Some of the tools used for this are similar to the main subject of this document of blocking and filtering. In particular, enterprise proxies might be part of a DLP solution.
データ損失防止（DLP）：企業やその他のネットワークは、偶発的または意図的なものかどうかにかかわらず、機密情報の漏洩の可能性を懸念しています。このために使用されるツールのいくつかは、このドキュメントのブロックとフィルタリングの主な主題に似ています。特に、エンタープライズプロキシはDLPソリューションの一部である可能性があります。
At a generic level, blocking systems can be characterized by four attributes: the party who sets the blocking policy, the purpose of the blocking, the intended target of the blocking, and the Internet component(s) used as the basis of the blocking system.
一般的なレベルでは、ブロッキングシステムは4つの属性によって特徴付けることができます：ブロッキングポリシーを設定する当事者、ブロッキングの目的、ブロッキングの意図されたターゲット、およびブロッキングシステムの基礎として使用されるインターネットコンポーネント。
Parties that institute blocking policies include governments, courts, enterprises, network operators, reputation trackers, application providers, and individual end users. A government might create laws based on cultural norms and/or their elected mandate. Enterprises might use cultural, industry, or legal norms to guide their policies.
ブロッキングポリシーを制定する当事者には、政府、裁判所、企業、ネットワークオペレーター、評判トラッカー、アプリケーションプロバイダー、および個々のエンドユーザーが含まれます。政府は、文化的規範および/または選ばれた権限に基づいて法律を作成する場合があります。企業は、文化、産業、または法的規範を使用してポリシーを導く場合があります。
There can be several steps of translation and transformation from the original intended purpose -- first to laws, then to (government) regulation, followed by high-level policies in, e.g., network operators, and from those policies to filtering architecture and implementation. Each of those steps is a potential source of unintended consequences as discussed in this document.
当初の目的から最初に法律に、次に（政府）規制に、次にネットワークオペレーターなどの高レベルのポリシーに続いて、それらのポリシーからフィルタリングアーキテクチャと実装に至るまで、変換と変換のいくつかのステップが存在する可能性があります。これらの各ステップは、このドキュメントで説明されているように、意図しない結果の潜在的な原因です。
In some cases, the policy setting entity is the same as the entity that enforces the policy. For example, a network operator might install a firewall in its own networking equipment, or a web application provider might block responses between its web server and certain clients.
場合によっては、ポリシー設定エンティティは、ポリシーを実施するエンティティと同じです。たとえば、ネットワークオペレーターが独自のネットワーク機器にファイアウォールをインストールしたり、WebアプリケーションプロバイダーがWebサーバーと特定のクライアント間の応答をブロックしたりする場合があります。
In other cases, the policy setting entity is different from the entity that enforces the policy. Such policy might be imposed upon the enforcing entity, such as in the case of blocking initiated by governments, or the enforcing entity might explicitly choose to use policy set by others, such as in the case of a reputation system used by a spam filter or safe browsing service. Because a policy might be enforced by others, it is best if it can be expressed in a form that is independent of the enforcing technology.
他の場合では、ポリシー設定エンティティは、ポリシーを実施するエンティティとは異なります。そのようなポリシーは、政府によって開始されたブロックの場合など、実施エンティティに課される場合があります。または、実施エンティティは、スパムフィルターによって使用されるレピュテーションシステムの場合など、他者によって設定されたポリシーを使用することを明示的に選択する場合があります。安全なブラウジングサービス。ポリシーは他の人によって施行される可能性があるため、施行テクノロジーとは独立した形式で表現できるのが最善です。
There are a variety of motivations to filter:
フィルタリングする動機はさまざまです。
o Preventing or responding to security threats. Network operators, enterprises, application providers, and end users often block communications that are believed to be associated with security threats or network attacks.
o セキュリティの脅威の防止または対応。ネットワークオペレーター、企業、アプリケーションプロバイダー、エンドユーザーは、セキュリティの脅威やネットワーク攻撃に関連すると考えられている通信をブロックすることがよくあります。
o Restricting objectionable content or services. Certain communications may be viewed as undesirable, harmful, or illegal by particular governments, enterprises, or users. Governments may seek to block communications that are deemed to be defamation, hate speech, obscenity, intellectual property infringement, or otherwise objectionable. Enterprises may seek to restrict employees from accessing content that is not deemed to be work appropriate. Parents may restrict their children from accessing content or services targeted for adults.
o 不快なコンテンツまたはサービスを制限する。特定の通信は、特定の政府、企業、またはユーザーによって、望ましくない、有害、または違法と見なされる場合があります。政府は、名誉毀損、悪意のある表現、わいせつ、知的財産権の侵害、またはその他の好ましくないと思われる通信をブロックしようとする場合があります。企業は、従業員が適切とは見なされないコンテンツへのアクセスを制限しようとする場合があります。保護者は、子供が大人向けのコンテンツやサービスにアクセスすることを制限できます。
o Restricting access based on business arrangements. Some networks are designed so as to only provide access to certain content or services ("walled gardens"), or to only provide limited access until end users pay for full Internet services (captive portals provided by hotspot operators, for example).
o ビジネスの取り決めに基づいてアクセスを制限する。一部のネットワークは、特定のコンテンツまたはサービス（「ウォールドガーデン」）へのアクセスのみを提供するように、またはエンドユーザーが完全なインターネットサービス（たとえば、ホットスポットオペレーターによって提供されるキャプティブポータル）に支払うまで、アクセスを制限するように設計されています。
Note that the purpose for which blocking occurs often dictates whether the blocking system operates on a blacklist model, where communications are allowed by default but a subset are blocked, or a whitelist model, where communications are blocked by default with only a subset allowed. Captive portals, walled gardens, and sandboxes used for security or network endpoint assessment usually require a whitelist model since the scope of communications allowed is narrow. Blocking for other purposes often uses a blacklist model since only individual content or traffic is intended to be blocked.
ブロッキングが発生する目的は、多くの場合、ブロッキングシステムが、通信はデフォルトで許可されているがサブセットはブロックされているブラックリストモデル、または通信がデフォルトでブロックされているサブセットのみが許可されているホワイトリストモデルで動作するかどうかを決定することに注意してください。セキュリティまたはネットワークエンドポイントの評価に使用されるキャプティブポータル、ウォールドガーデン、サンドボックスでは、許可される通信の範囲が狭いため、通常はホワイトリストモデルが必要です。個々のコンテンツまたはトラフィックのみをブロックすることを目的としているため、他の目的でのブロックは、多くの場合ブラックリストモデルを使用します。
Blocking systems are instituted so as to target particular content, services, endpoints, or some combination of these. For example, a "content" filtering system used by an enterprise might block access to specific URIs whose content is deemed by the enterprise to be inappropriate for the workplace. This is distinct from a "service" filtering system that blocks all web traffic (perhaps as part of a parental control system on an end-user device) and also distinct from an "endpoint" filtering system in which a web application blocks traffic from specific endpoints that are suspected of malicious activity.
ブロッキングシステムは、特定のコンテンツ、サービス、エンドポイント、またはこれらの組み合わせを対象とするように設定されています。たとえば、企業が使用する「コンテンツ」フィルタリングシステムは、企業によってコンテンツが職場に不適切であると見なされる特定のURIへのアクセスをブロックする場合があります。これは、すべてのWebトラフィックをブロックする「サービス」フィルタリングシステムとは異なり（おそらくエンドユーザーデバイスのペアレンタルコントロールシステムの一部として）、Webアプリケーションが特定のトラフィックをブロックする「エンドポイント」フィルタリングシステムとも異なります。悪意のあるアクティビティが疑われるエンドポイント。
As discussed in Section 4, the design of a blocking system may affect content, services, or endpoints other than those that are the intended targets. For example, when domain name seizures described above are intended to address specific web pages associated with illegal activity, by removing the domains from use, they affect all services made available by the hosts associated with those names, including mail services and web services that may be unrelated to the illegal activity. Depending on where the block is imposed within the DNS hierarchy, entirely unrelated organizations may be impacted.
セクション4で説明したように、ブロッキングシステムの設計は、意図されたターゲット以外のコンテンツ、サービス、またはエンドポイントに影響を与える可能性があります。たとえば、上記のドメイン名の差し押さえが不法な活動に関連する特定のWebページに対処することを目的としている場合、ドメインを使用から削除することで、それらの名前に関連するホストが利用できるすべてのサービスに影響を与えます。違法行為とは無関係である。 DNS階層内でブロックが課される場所によっては、まったく関係のない組織が影響を受ける可能性があります。
Broadly speaking, the process of delivering an Internet service involves three different components:
大まかに言って、インターネットサービスを提供するプロセスには、3つの異なるコンポーネントが含まれます。
1. Endpoints: The actual content of the service is typically an application-layer protocol between two or more Internet hosts. In many protocols, there are two endpoints, a client and a server.
1. エンドポイント：通常、サービスの実際のコンテンツは、2つ以上のインターネットホスト間のアプリケーション層プロトコルです。多くのプロトコルには、クライアントとサーバーの2つのエンドポイントがあります。
2. Network services: The endpoints communicate by way of a collection of IP networks that use routing protocols to determine how to deliver packets between the endpoints.
2. ネットワークサービス：エンドポイントは、ルーティングプロトコルを使用してエンドポイント間でパケットを配信する方法を決定するIPネットワークのコレクションを介して通信します。
3. Rendezvous services: Service endpoints are typically identified by identifiers that are more "human-friendly" than IP addresses. Rendezvous services allow one endpoint to figure out how to contact another endpoint based on an identifier. An example of a rendezvous service is the domain name system. Distributed Hash Tables (DHTs) have also been used as rendezvous services.
3. ランデブーサービス：サービスエンドポイントは通常、IPアドレスよりも「人に優しい」識別子によって識別されます。ランデブーサービスを使用すると、あるエンドポイントが、識別子に基づいて別のエンドポイントに接続する方法を把握できます。ランデブーサービスの例は、ドメインネームシステムです。分散ハッシュテーブル（DHT）もランデブーサービスとして使用されています。
Consider, for example, an HTTP transaction fetching the content of the URI <http://example.com/index.html>. The client endpoint is an end host running a browser. The client uses the DNS as a rendezvous service when it performs a AAAA query to obtain the IP address for the server name "example.com". The client then establishes a connection to the server, and sends the actual HTTP request. The server endpoint then responds to the HTTP request.
たとえば、URI <http://example.com/index.html>のコンテンツをフェッチするHTTPトランザクションを考えてみます。クライアントエンドポイントは、ブラウザを実行しているエンドホストです。クライアントは、AAAAクエリを実行してサーバー名「example.com」のIPアドレスを取得するときに、DNSをランデブーサービスとして使用します。次に、クライアントはサーバーへの接続を確立し、実際のHTTP要求を送信します。次に、サーバーエンドポイントはHTTP要求に応答します。
As another example, in the SIP protocol, the two endpoints communicating are IP phones, and the rendezvous service is provided by an application-layer SIP proxy as well as the DNS.
別の例として、SIPプロトコルでは、通信する2つのエンドポイントはIP電話であり、ランデブーサービスはアプリケーション層のSIPプロキシとDNSによって提供されます。
Blocking access to Internet content, services, or endpoints is done by controlling one or more of the components involved in the provision of the communications involved in accessing the content, services, or endpoints. In the HTTP example above, the successful completion of the HTTP request could have been prevented in several ways:
インターネットコンテンツ、サービス、またはエンドポイントへのアクセスをブロックするには、コンテンツ、サービス、またはエンドポイントへのアクセスに関連する通信のプロビジョニングに関連する1つ以上のコンポーネントを制御します。上記のHTTPの例では、HTTPリクエストの正常な完了がいくつかの方法で妨げられている可能性があります。
o [Endpoint] Preventing the client from making the request
o [エンドポイント]クライアントがリクエストを行わないようにする
o [Endpoint] Preventing the server from responding to the request
o [エンドポイント]サーバーがリクエストに応答しないようにする
o [Endpoint] Preventing the client from making the DNS request needed to resolve example.com
o [エンドポイント]クライアントがexample.comを解決するために必要なDNSリクエストを作成できないようにする
o [Network] Preventing the request from reaching the server o [Network] Preventing the response from reaching the client
o [ネットワーク]リクエストがサーバーに到達しないようにするo [ネットワーク]レスポンスがクライアントに到達しないようにする
o [Network] Preventing the client from reaching the DNS servers
o [ネットワーク]クライアントがDNSサーバーに到達しないようにする
o [Network] Preventing the DNS responses from reaching the client
o [ネットワーク] DNS応答がクライアントに到達しないようにする
o [Rendezvous] Preventing the DNS servers from providing the client the correct IP address of the server
o [ランデブー] DNSサーバーがクライアントにサーバーの正しいIPアドレスを提供できないようにする
Those who desire to block communications will typically have access to only one or two components; therefore their choices for how to perform blocking will be limited. End users and application providers can usually only control their own software and hardware, which means that they are limited to endpoint-based filtering. Some network operators offer filtering services that their customers can activate individually, in which case end users might have network-based filtering systems available to them. Network operators can control their own networks and the rendezvous services for which they provide infrastructure support (e.g., DNS resolvers) or to which they may have access (e.g., SIP proxies), but not usually endpoints. Enterprises usually have access to their own networks and endpoints for filtering purposes. Governments might make arrangements with the operators or owners of any of the three components that exist within their jurisdictions to perform filtering.
通信をブロックしたい人は、通常、1つまたは2つのコンポーネントにしかアクセスできません。したがって、ブロッキングを実行する方法についての選択肢は制限されます。エンドユーザーとアプリケーションプロバイダーは通常、自分のソフトウェアとハードウェアのみを制御できます。つまり、エンドポイントベースのフィルタリングに制限されます。一部のネットワークオペレーターは、顧客が個別にアクティブ化できるフィルターサービスを提供しています。この場合、エンドユーザーはネットワークベースのフィルターシステムを利用できる場合があります。ネットワークオペレーターは、インフラストラクチャサポート（例：DNSリゾルバー）を提供する、またはアクセス権（例：SIPプロキシ）を持つ独自のネットワークとランデブーサービスを制御できますが、通常はエンドポイントを制御できません。企業は通常、フィルタリングのために独自のネットワークとエンドポイントにアクセスできます。政府は、管轄区域内に存在する3つのコンポーネントのいずれかのオペレーターまたは所有者と、フィルタリングを実行するように手配する場合があります。
In the next section, blocking systems designed according to each of the three patterns -- network services, rendezvous services, and endpoints -- are evaluated for their technical and architectural implications. The analysis is as agnostic as possible as to who sets the blocking policy (government, end user, network operator, application provider, or enterprise), but in some cases the way in which a particular blocking design pattern is used might differ, depending on the who desires a block. For example, a network-based firewall provided by an ISP that parents can elect to use for parental control purposes will likely function differently from one that all ISPs in a particular jurisdiction are required to use by the local government, even though in both cases the same component (network) forms the basis of the blocking system.
次のセクションでは、3つのパターン（ネットワークサービス、ランデブーサービス、エンドポイント）のそれぞれに従って設計されたブロッキングシステムについて、技術的およびアーキテクチャ上の影響について評価します。分析は、誰がブロッキングポリシーを設定するか（政府、エンドユーザー、ネットワークオペレーター、アプリケーションプロバイダー、またはエンタープライズ）に関してできるだけ不可知論的ですが、場合によっては、特定のブロッキングデザインパターンの使用方法が異なります。ブロックを望む人。たとえば、保護者がペアレンタルコントロールの目的で使用することを選択できるISPによって提供されるネットワークベースのファイアウォールは、特定の管轄区域のすべてのISPが地方自治体で使用する必要があるものとは機能が異なる可能性があります。同じコンポーネント（ネットワーク）がブロッキングシステムの基礎を形成します。
To evaluate the technical implications of each of the blocking design patterns, we compare them based on four criteria: scope, granularity, efficacy, and security.
各ブロッキングデザインパターンの技術的な影響を評価するために、4つの基準（スコープ、粒度、有効性、およびセキュリティ）に基づいてそれらを比較します。
The Internet is comprised of many distinct autonomous networks and applications, which means that the impact of a blocking system will only be within a defined topological scope. For example, blocking within an access network will only affect a well-defined set of users (namely, those connected to the access network). Blocking performed by an application provider can affect users across the entire Internet.
インターネットは、多くの異なる自律ネットワークとアプリケーションで構成されています。つまり、ブロッキングシステムの影響は、定義されたトポロジーの範囲内に限定されます。たとえば、アクセスネットワーク内でのブロックは、明確に定義されたユーザーのセット（つまり、アクセスネットワークに接続されているユーザー）にのみ影響します。アプリケーションプロバイダーによって実行されるブロックは、インターネット全体のユーザーに影響を与える可能性があります。
Blocking systems are generally viewed as less objectionable if the scope of their impact is as narrow as possible while still being effective, and as long as the impact of the blocking is within the administrative realm of the policy setting entity. As mentioned previously, enterprise blocking systems are commonly deployed, and will generally have impact on enterprise users. However, design flaws in blocking systems may cause the effects of blocking to be overbroad. For example, at least one service provider blocking content in accordance with a regulation has ended up blocking content for downstream service providers because it filtered routes to particular systems and did not distribute the original information to downstream service providers in other jurisdictions [IN-OM-filtering]. Other service providers have accidentally leaked such black hole routes beyond the jurisdiction [NW08]. A substantial amount of work has gone into BGP security to avoid such attacks, but deployment of such systems lags.
ブロッキングシステムは、その影響の範囲が可能な限り狭く、効果的であり、かつ、ブロッキングの影響がポリシー設定エンティティの管理領域内にある限り、一般に不快感が少ないと見なされます。前述のように、エンタープライズブロッキングシステムは一般的に導入されており、一般にエンタープライズユーザーに影響を与えます。ただし、ブロッキングシステムの設計上の欠陥により、ブロッキングの影響が広範囲に及ぶ可能性があります。たとえば、規制に従ってコンテンツをブロックしている少なくとも1つのサービスプロバイダーは、特定のシステムへのルートをフィルタリングし、他の管轄区域のダウンストリームサービスプロバイダーに元の情報を配信しなかったため、ダウンストリームサービスプロバイダーのコンテンツをブロックしました[IN-OM-フィルタリング]。他のサービスプロバイダーは、管轄権を超えてこのようなブラックホールルートを誤って漏らしました[NW08]。このような攻撃を回避するために、BGPセキュリティにかなりの作業が費やされていますが、そのようなシステムの展開は遅れています。
4.1.2. Granularity: How specific is the blocking? Will blocking one service also block others?
4.1.2. 粒度：ブロッキングはどの程度具体的ですか？ 1つのサービスをブロックすると、他のサービスもブロックされますか？
Internet applications are built out of a collection of loosely coupled components or "layers". Different layers serve different purposes and rely on or offer different functions such as routing, transport, and naming (see [RFC1122], especially Section 1.1.3). The functions at these layers are developed autonomously and almost always operated by different parties. For example, in many networks, physical and link-layer connectivity is provided by an "access provider", IP routing is performed by an "Internet service provider," and application-layer services are provided by completely separate entities (e.g., web servers). Upper-layer protocols and applications rely on combinations of lower-layer functions in order to work. Functionality at higher layers tends to be more specialized, so that many different specialized applications can make use of the same generic underlying network functions.
インターネットアプリケーションは、疎結合コンポーネントまたは「レイヤー」のコレクションから構築されます。異なる層は異なる目的を果たし、ルーティング、トランスポート、ネーミングなどの異なる機能に依存または提供します（[RFC1122]、特にセクション1.1.3を参照）。これらの層の機能は自律的に開発され、ほとんどの場合、さまざまな関係者によって操作されます。たとえば、多くのネットワークでは、物理的およびリンク層の接続は「アクセスプロバイダー」によって提供され、IPルーティングは「インターネットサービスプロバイダー」によって実行され、アプリケーション層のサービスは完全に別個のエンティティ（たとえば、Webサーバー）によって提供されます。 ）。上位層のプロトコルとアプリケーションは、機能するために下位層の機能の組み合わせに依存しています。上位層の機能はより専門化される傾向があるため、多くの異なる専門化されたアプリケーションが、同じ一般的な基礎となるネットワーク機能を利用できます。
As a result of this structure, actions taken at one layer can affect functionality or applications at other layers. For example, manipulating routing or naming functions to restrict access to a narrow set of resources via specific applications will likely affect all applications that depend on those functions. As with the scope criteria, blocking systems are generally viewed as less objectionable when they are highly granular and do not cause collateral damage to content or services unrelated to the target of the blocking [RFC4924].
この構造の結果として、1つの層で実行されるアクションは、他の層の機能またはアプリケーションに影響を与える可能性があります。たとえば、特定のアプリケーションを介して限られたリソースセットへのアクセスを制限するためにルーティングまたは命名関数を操作すると、それらの関数に依存するすべてのアプリケーションに影響を与える可能性があります。範囲の基準と同様に、ブロックシステムは、非常に細かく、ブロックの対象に関係のないコンテンツやサービスに付随的な損害を引き起こさない場合、一般的に不快感は少ないと見なされます[RFC4924]。
Even within the application layer, the granularity of blocking can vary depending on how targeted the blocking system is designed to be. Blocking all traffic associated with a particular application protocol is less granular than blocking only traffic associated with a subset of application instances that make use of that protocol. Sophisticated heuristics that make use of information about the application protocol, lower-layer protocols, payload signatures, source and destination addresses, inter-packet timing, packet sizes, and other characteristics are sometimes used to narrow the subset of traffic to be blocked.
アプリケーション層内でも、ブロッキングの細分性は、ブロッキングシステムの設計対象に応じて異なります。特定のアプリケーションプロトコルに関連付けられたすべてのトラフィックをブロックすることは、そのプロトコルを使用するアプリケーションインスタンスのサブセットに関連付けられたトラフィックのみをブロックすることよりも粒度が低くなります。アプリケーションプロトコル、下位層プロトコル、ペイロードシグネチャ、送信元アドレスと宛先アドレス、パケット間タイミング、パケットサイズ、およびその他の特性に関する情報を利用する高度なヒューリスティックは、ブロックされるトラフィックのサブセットを絞り込むために使用されることがあります。
4.1.3. Efficacy: How easy is it for a resource or service to avoid being blocked?
4.1.3. 有効性：リソースまたはサービスがブロックされるのを避けるのはどれほど簡単ですか？
Although blocking a resource or service might have some immediate effect, efficacy must be evaluated in terms of whether it is easy to circumvent. Simply doing a one-time policy is often unlikely to have lasting efficacy (e.g., see [CleanFeed] and [BlackLists14]). Experience has shown that, in general, blacklisting requires continual maintenance of the blacklist itself, both to add new entries for unwanted traffic and deleting entries when offending content is removed. Experience also shows that, depending on the nature of the block, it may be difficult to determine when to unblock. For instance, if a host is blocked because it has been compromised and used as a source of attack, it may not be plainly evident when that site has been fixed.
リソースまたはサービスをブロックするとすぐに影響が出る可能性がありますが、効果を回避するのが簡単かどうかで評価する必要があります。 1回限りのポリシーを実行するだけでは、効果が持続することはほとんどありません（たとえば、[CleanFeed]と[BlackLists14]を参照）。経験によると、一般に、ブラックリストを作成するには、不要なトラフィックの新しいエントリを追加したり、問題のコンテンツが削除されたときにエントリを削除したりするために、ブラックリスト自体を継続的に保守する必要があります。また、ブロックの性質によっては、ブロックを解除するタイミングを決定するのが難しい場合があることも経験からわかっています。たとえば、ホストが侵害されて攻撃元として使用されたためにホストがブロックされている場合、そのサイトが修正されたときにホストが明確に見えない可能性があります。
For blacklist-style blocking, the distributed and mobile nature of Internet resources limits the effectiveness of blocking actions. A service that is blocked in one jurisdiction can often be moved or re-instantiated in another jurisdiction (see, for example, [Malicious-Resolution]). Likewise, services that rely on blocked resources can often be rapidly reconfigured to use non-blocked resources. If a web site is prevented from using a domain name or set of IP addresses, the content can simply be moved to another domain name or network, or use alternate syntaxes to express the same resource name (see the discussion of false negatives in [RFC6943]).
ブラックリストスタイルのブロックの場合、インターネットリソースの分散型およびモバイルの性質により、ブロックアクションの効果が制限されます。ある管轄でブロックされているサービスは、別の管轄で移動または再インスタンス化されることがよくあります（たとえば、[悪意のある解決策]を参照）。同様に、ブロックされたリソースに依存するサービスは、多くの場合、ブロックされていないリソースを使用するように迅速に再構成できます。 Webサイトがドメイン名またはIPアドレスのセットを使用できない場合は、コンテンツを別のドメイン名またはネットワークに移動するか、別の構文を使用して同じリソース名を表現することができます（[RFC6943 ]）。
In a process known as "snowshoe spamming," a spam originator uses addresses in many different networks as sources for spam. This technique is already widely used to spread spam generation across a variety of resources and jurisdictions to prevent spam blocking from being effective.
「スノーシュースパム」として知られるプロセスでは、スパム発信者は、さまざまなネットワークのアドレスをスパムの送信元として使用します。この手法は、スパムのブロックが効果的でないようにするために、さまざまなリソースと管轄区域にスパムの生成を分散させるためにすでに広く使用されています。
In the presence of either blacklist or whitelist systems, there are several ways in which a user or application can try to circumvent the filters.
ブラックリストシステムまたはホワイトリストシステムのいずれかが存在する場合、ユーザーまたはアプリケーションがフィルターを回避しようとするいくつかの方法があります。
The users may choose to use different sets of protocols or otherwise alter their traffic characteristics to circumvent the filters. In some cases, applications may shift their traffic to port 80 or 443 when other ports are blocked. Or, services may be tunneled within other services, proxied by a collaborating external host (e.g., an anonymous redirector), or simply run over an alternate port (e.g., port 8080 vs port 80 for HTTP). Another means of circumvention is alteration of the service behavior to use a dynamic port negotiation phase, in order to avoid use of a constant port address.
ユーザーは、異なるプロトコルのセットを使用するか、フィルターを回避するためにトラフィック特性を変更するかを選択できます。場合によっては、他のポートがブロックされているときに、アプリケーションがトラフィックをポート80または443にシフトすることがあります。または、サービスは他のサービス内でトンネリングされたり、協力している外部ホスト（匿名リダイレクタなど）によってプロキシされたり、単に代替ポート（たとえば、HTTPのポート8080とポート80）で実行されたりします。回避策のもう1つの方法は、動的ポートネゴシエーションフェーズを使用するようにサービス動作を変更して、一定のポートアドレスの使用を回避することです。
One of the primary motivations for arguing that HTTP/2 should be encrypted by default was that unencrypted HTTP 1.1 traffic was sometimes blocked or improperly processed. Users or applications shifting their traffic to encrypted HTTP has the effect of circumventing filters that depend on the HTTP plaintext payload.
HTTP / 2をデフォルトで暗号化する必要があると主張する主な動機の1つは、暗号化されていないHTTP 1.1トラフィックが時々ブロックされるか、不適切に処理されることでした。トラフィックを暗号化されたHTTPにシフトするユーザーまたはアプリケーションには、HTTPプレーンテキストペイロードに依存するフィルターを回避する効果があります。
If voice communication based on SIP [RFC3261] is blocked, users are likely to use applications which use proprietary protocols that allow them to talk to each other.
SIP [RFC3261]に基づく音声通信がブロックされている場合、ユーザーは相互に通信できる独自のプロトコルを使用するアプリケーションを使用する可能性があります。
Some filtering systems are only capable of identifying IPv4 traffic and therefore, by shifting to IPv6, users may be able to evade filtering. Using IPv6 with header options, using multiple layers of tunnels, or using encrypted tunnels can also make it more challenging for blocking systems to find transport ports within packets, making port-based blocking more difficult. Thus, distribution and mobility can hamper efforts to block communications in a number of ways.
一部のフィルタリングシステムはIPv4トラフィックしか識別できないため、IPv6に移行することで、ユーザーはフィルタリングを回避できる場合があります。ヘッダーオプションでIPv6を使用したり、トンネルの複数のレイヤーを使用したり、暗号化されたトンネルを使用したりすると、ブロッキングシステムがパケット内のトランスポートポートを見つけることが難しくなり、ポートベースのブロッキングが困難になります。このように、配布とモビリティは、さまざまな方法で通信をブロックする取り組みを妨げる可能性があります。
4.1.4. Security: How does the blocking impact existing trust infrastructures?
4.1.4. セキュリティ：ブロックは既存の信頼インフラストラクチャにどのように影響しますか？
Modern security mechanisms rely on trusted hosts communicating via a secure channel without intermediary interference. Protocols such as Transport Layer Security (TLS) [RFC5246] and IPsec [RFC4301] are designed to ensure that each endpoint of the communication knows the identity of the other endpoint(s) and that only the endpoints of the communication can access the secured contents of the communication. For example, when a user connects to a bank's web site, TLS ensures that the user's banking information is securely communicated to the bank and nobody else, ensuring the data remains confidential while in transit.
最新のセキュリティメカニズムは、中間の干渉なしに安全なチャネルを介して通信する信頼できるホストに依存しています。トランスポート層セキュリティ（TLS）[RFC5246]やIPsec [RFC4301]などのプロトコルは、通信の各エンドポイントが他のエンドポイントのIDを確実に認識し、通信のエンドポイントのみが保護されたコンテンツにアクセスできるように設計されていますコミュニケーションの。たとえば、ユーザーが銀行のWebサイトに接続すると、TLSはユーザーの銀行情報が銀行に安全に通信され、他の誰にも通信されないようにし、転送中のデータの機密性を確保します。
Some blocking strategies require intermediaries to insert themselves within the end-to-end communications path, potentially breaking security properties of Internet protocols [RFC4924]. In these cases, it can be difficult or impossible for endpoints to distinguish between attackers and "authorized" parties conducting blocking. For example, an enterprise firewall administrator could gain access to users' personal bank accounts when users on the enterprise network connect to bank web sites.
一部のブロック戦略では、中間者がエンドツーエンドの通信パス内に自分自身を挿入する必要があり、インターネットプロトコルのセキュリティプロパティを破壊する可能性があります[RFC4924]。これらの場合、エンドポイントがブロッキングを実行している攻撃者と「許可された」当事者を区別することは困難または不可能である可能性があります。たとえば、エンタープライズファイアウォールの管理者は、エンタープライズネットワーク上のユーザーが銀行のWebサイトに接続すると、ユーザーの個人の銀行口座にアクセスできます。
Finally, one needs to evaluate whether a blocking mechanism can be used by an end user to efficiently locate blocked resources that can then be accessed via other mechanisms that circumvent the blocking mechanism. For example, Clayton [CleanFeed] showed how special treatment in one blocking system could be detected by end users in order to efficiently locate illegal web sites, which was thus counterproductive to the policy objective of the blocking mechanism.
最後に、ブロックメカニズムを回避する他のメカニズムを介してアクセスできるブロックされたリソースを効率的に見つけるために、エンドユーザーがブロックメカニズムを使用できるかどうかを評価する必要があります。たとえば、Clayton [CleanFeed]は、違法なWebサイトを効率的に見つけるために、1つのブロックシステムの特別な処理をエンドユーザーが検出できることを示しました。
Being able to block access to resources without the consent or cooperation of either endpoint is viewed as a desirable feature by some that deploy blocking systems. Systems that have this property are often implemented using intermediary devices in the network, such as firewalls or filtering systems. These systems inspect traffic as it passes through the network, decide based on the characteristics or content of a given communication whether it should be blocked, and then block or allow the communication as desired. For example, web filtering devices usually inspect HTTP requests to determine the URI being requested, compare that URI to a list of blacklisted or whitelisted URIs, and allow the request to proceed only if it is permitted by policy. Firewalls perform a similar function for other classes of traffic in addition to HTTP. Some blocking systems focus on specific application-layer traffic, while others, such as router Access Control Lists (ACLs), filter traffic based on lower-layer criteria (transport protocol and source or destination addresses or ports).
いずれかのエンドポイントの同意または協力なしにリソースへのアクセスをブロックできることは、ブロッキングシステムを展開する一部の企業にとって望ましい機能と見なされています。この特性を持つシステムは、ファイアウォールやフィルタリングシステムなど、ネットワーク内の中間デバイスを使用して実装されることがよくあります。これらのシステムは、ネットワークを通過するトラフィックを検査し、特定の通信の特性または内容に基づいてブロックするかどうかを決定し、必要に応じて通信をブロックまたは許可します。たとえば、ウェブフィルタリングデバイスは通常、HTTPリクエストを検査してリクエストされているURIを特定し、そのURIをブラックリストまたはホワイトリストのURIのリストと比較して、ポリシーで許可されている場合にのみリクエストを続行できるようにします。ファイアウォールは、HTTPに加えて、他のクラスのトラフィックに対しても同様の機能を実行します。一部のブロッキングシステムは特定のアプリケーション層のトラフィックに焦点を当てていますが、ルーターアクセスコントロールリスト（ACL）などの他のシステムは、下位層の基準（トランスポートプロトコルと送信元または宛先のアドレスまたはポート）に基づいてトラフィックをフィルターします。
Intermediary systems used for blocking are often not far from the edge of the network. For example, many enterprise networks operate firewalls that block certain web sites, as do some residential ISPs. In some cases, this filtering is done with the consent or cooperation of the affected endpoints. PCs within an enterprise, for example, might be configured to trust an enterprise proxy, a residential ISP might offer a "safe browsing" service, or mail clients might authorize mail servers on the local network to filter spam on their behalf. These cases share some of the properties of the "Endpoint-Based Blocking" scenarios discussed in Section 4.4 below, since the endpoint has made an informed decision to authorize the intermediary to block on its behalf and is therefore unlikely to attempt to circumvent the blocking. From an architectural perspective, however, they may create many of the same problems as network-based filtering conducted without consent.
ブロッキングに使用される中間システムは、多くの場合、ネットワークのエッジからそれほど遠くありません。たとえば、多くの企業ネットワークは、一部の住宅用ISPと同様に、特定のWebサイトをブロックするファイアウォールを運用しています。場合によっては、このフィルタリングは、影響を受けるエンドポイントの同意または協力を得て行われます。たとえば、企業内のPCは企業プロキシを信頼するように構成され、住宅用ISPは「安全なブラウジング」サービスを提供し、メールクライアントはローカルネットワーク上のメールサーバーに代理でスパムをフィルタリングすることを許可します。これらのケースは、以下のセクション4.4で説明する「エンドポイントベースのブロッキング」シナリオのプロパティの一部を共有します。エンドポイントは、仲介者がその代わりにブロックすることを承認するための情報に基づいた決定を行ったため、ブロッキングを回避しようとする可能性が低いためです。ただし、アーキテクチャの観点からは、同意なしに行われるネットワークベースのフィルタリングと同じ問題の多くを引き起こす可能性があります。
In the case of government-initiated blocking, network operators subject to a specific jurisdiction may be required to block or filter. Thus, it is possible for laws to be structured to result in blocking by imposing obligations on the operators of networks within a jurisdiction, either via direct government action or by allowing private actors to demand blocking (e.g., through lawsuits).
政府主導のブロッキングの場合、特定の管轄下にあるネットワークオペレーターは、ブロックまたはフィルタリングする必要があります。したがって、管轄区域内のネットワークの運営者に、直接の政府の行動を介して、または民間の主体に（訴訟などを通じて）ブロックを要求することを許可することによって義務を課すことによって、ブロックが発生するように法律を構成することが可能です。
Regardless of who is responsible for a blocking policy, enforcement can be done using Stateless Packet Filtering, Stateful Packet Filtering, or Deep Packet Inspection as defined in Section 2. While network-based Stateless Packet Filtering has granularity issues discussed in Section 4.2.2, network-based Stateful Packet Filtering and Deep Packet Inspection approaches often run into several technical issues that limit their viability in practice. For example, many issues arise from the fact that an intermediary needs to have access to a sufficient amount of traffic to make its blocking determinations.
ブロッキングポリシーの責任者に関係なく、強制は、セクション2で定義されているステートレスパケットフィルタリング、ステートフルパケットフィルタリング、またはディープパケットインスペクションを使用して実行できます。ネットワークベースのステートレスパケットフィルタリングには、セクション4.2.2で説明されている粒度の問題がありますが、ネットワークベースのステートフルパケットフィルタリングとディープパケットインスペクションのアプローチは、実際の実行可能性を制限するいくつかの技術的な問題に遭遇することがよくあります。たとえば、多くの問題は、仲介者が十分な量のトラフィックにアクセスして、ブロックを決定する必要があるという事実から生じます。
For residential or consumer networks with many egress points, the first step to obtaining this traffic is simply gaining access to the constituent packets. The Internet is designed to deliver packets independently from source to destination -- not to any particular point along the way. Thus, the sequence of packets from the sender can only be reliably reconstructed at the intended receiver. In addition, inter-network routing is often asymmetric, and for sufficiently complex local networks, intra-network traffic flows can be asymmetric as well [asymmetry]. Thus, packets in the reverse direction use a different sent of paths than the forward direction.
多くの出力ポイントがある住宅用ネットワークまたはコンシューマーネットワークの場合、このトラフィックを取得するための最初のステップは、構成パケットへのアクセスを取得することです。インターネットは、送信元から宛先にパケットを個別に配信するように設計されています。途中の特定のポイントには配信されません。したがって、送信側からのパケットのシーケンスは、意図した受信側でのみ確実に再構築できます。さらに、ネットワーク間のルーティングは非対称であることが多く、十分に複雑なローカルネットワークでは、ネットワーク内のトラフィックフローも非対称になる可能性があります[非対称]。したがって、逆方向のパケットは、順方向とは異なる送信パスを使用します。
This asymmetry means that an intermediary in a network with many egress points may, depending on topology and configuration, see only one half of a given communication, which may limit the scope of the communications that it can filter. For example, a filter aimed at requests destined for particular URIs cannot make accurate blocking decisions based on the URI if it is only in the data path for HTTP responses and not requests, since the URI is not included in the responses. Asymmetry may be surmountable given a filtering system with enough distributed, interconnected filtering nodes that can coordinate information about flows belonging to the same communication or transaction, but depending on the size of the network this may imply significant complexity in the filtering system. Routing can sometimes be forced to be symmetric within a given network using routing configuration, NAT, or Layer 2 mechanisms (e.g., MPLS), but these mechanisms are frequently brittle, complex, and costly -- and can sometimes result in reduced network performance relative to asymmetric routing. Enterprise networks may also be less susceptible to these problems if they route all traffic through a small number of egress points.
この非対称性は、多くの出力ポイントがあるネットワークの仲介者が、トポロジと構成に応じて、特定の通信の半分しか表示しない場合があり、フィルタリングできる通信の範囲を制限する可能性があることを意味します。たとえば、特定のURIを宛先とする要求を対象としたフィルターは、HTTP応答のデータパスのみにあり、要求に含まれていない場合、URIが応答に含まれていないため、URIに基づいて正確なブロックを決定できません。非対称性は、同じ通信またはトランザクションに属するフローに関する情報を調整できる、十分に分散され相互接続されたフィルタリングノードを備えたフィルタリングシステムで克服できますが、ネットワークのサイズによっては、フィルタリングシステムがかなり複雑になる可能性があります。ルーティングは、ルーティング構成、NAT、またはレイヤー2メカニズム（MPLSなど）を使用して、特定のネットワーク内で対称になるように強制される場合がありますが、これらのメカニズムは、もろく、複雑で、コストがかかることが多く、場合によっては、相対的にネットワークパフォーマンスが低下することがあります。非対称ルーティングに。エンタープライズネットワークは、すべてのトラフィックを少数の出力ポイント経由でルーティングする場合、これらの問題の影響を受けにくい場合もあります。
Once an intermediary in a network has access to traffic, it must identify which packets must be filtered. This decision is usually based on some combination of information at the network layer (e.g., IP addresses), transport layer (ports), or application layer (URIs or other content). Deep Packet Inspection type blocking based on application-layer attributes can be potentially more granular and less likely to cause collateral damage than blocking all traffic associated with a particular address, which can impact unrelated occupants of the same address. However, more narrowly focused targeting may be more complex, less efficient, or easier to circumvent than filtering that sweeps more broadly, and those who seek to block must balance these attributes against each other when choosing a blocking system.
ネットワークの仲介者がトラフィックにアクセスできるようになると、フィルタリングする必要のあるパケットを特定する必要があります。この決定は通常、ネットワーク層（IPアドレスなど）、トランスポート層（ポート）、またはアプリケーション層（URIまたはその他のコンテンツ）での情報のいくつかの組み合わせに基づいています。アプリケーションレイヤー属性に基づくディープパケットインスペクションタイプのブロックは、特定のアドレスに関連付けられたすべてのトラフィックをブロックするよりも、より細かく、付随的な損傷を引き起こす可能性が低く、同じアドレスの無関係な占有者に影響を与える可能性があります。ただし、より狭い範囲に絞ったターゲティングは、より広範囲にスイープするフィルタリングよりも複雑で、効率が悪く、回避が容易な場合があります。また、ブロックしようとするユーザーは、ブロックシステムを選択するときに、これらの属性のバランスをとる必要があります。
Regardless of the layer at which blocking occurs, it may be open to circumvention, particularly in cases where network endpoints have not authorized the blocking. The communicating endpoints can deny the intermediary access to attributes at any layer by using encryption (see below). IP addresses must be visible, even if packets are protected with IPsec, but blocking based on IP addresses can be trivial to circumvent. A filtered site may be able to quickly change its IP address using only a few simple steps: changing a single DNS record and provisioning the new address on its server or moving its services to the new address [BT-TPB].
ブロッキングが発生するレイヤーに関係なく、特にネットワークエンドポイントがブロッキングを許可していない場合は、それは回避策を受け入れる可能性があります。通信するエンドポイントは、暗号化を使用して、任意のレイヤーの属性への中間アクセスを拒否できます（以下を参照）。パケットがIPsecで保護されている場合でも、IPアドレスは可視である必要がありますが、IPアドレスに基づくブロックは簡単に回避できます。フィルターされたサイトは、いくつかの簡単な手順（単一のDNSレコードの変更とサーバーでの新しいアドレスのプロビジョニング、またはサービスの新しいアドレスへの移動[BT-TPB]）を使用して、IPアドレスをすばやく変更できる場合があります。
Indeed, Poort, et al. [Poort] found that "any behavioural change in response to blocking access to The Pirate Bay has had no lasting net impact on the overall number of downloaders from illegal sources, as new consumers have started downloading from illegal sources and people learn to circumvent the blocking while new illegal sources may be launched, causing file sharing to increase again", and that these results "are in line with a tendency found in the literature that any effects of legal action against file sharing often fade out after a period of typically six months."
確かに、Poortら。 [Poort]によると、「The Pirate Bayへのアクセスのブロックに対する応答の行動変化は、新しい消費者が違法なソースからのダウンロードを開始し、人々がブロックを回避することを学ぶようになるため、違法なソースからのダウンローダーの総数に永続的な影響を与えません一方、新しい違法ソースが起動され、ファイル共有が再び増加する可能性があります」、そしてこれらの結果は「ファイル共有に対する法的措置の影響は通常6か月の期間が経過すると消えるという文献に見られる傾向と一致しています」 」
If application content is encrypted with a security protocol such as IPsec or TLS, then the intermediary will require the ability to decrypt the packets to examine application content, or resort to statistical methods to guess what the content is. Since security protocols are generally designed to provide end-to-end security (i.e., to prevent intermediaries from examining content), the intermediary would need to masquerade as one of the endpoints, breaking the authentication in the security protocol, reducing the security of the users and services affected, and interfering with legitimate private communication. Besides, various techniques that use public databases with whitelisted keys (e.g., DANE [RFC6698]) enable users to detect these sort of intermediaries. Those users are then likely to act as if the service is blocked.
アプリケーションコンテンツがIPsecやTLSなどのセキュリティプロトコルで暗号化されている場合、仲介者はパケットを復号化してアプリケーションコンテンツを調べるか、統計的手法を使用してコンテンツを推測する機能を必要とします。セキュリティプロトコルは一般にエンドツーエンドのセキュリティを提供するように設計されているため（つまり、仲介者がコンテンツを検査しないようにするため）、仲介者はエンドポイントの1つになりすまして、セキュリティプロトコルの認証を破り、セキュリティを低下させる必要があります。影響を受けるユーザーとサービス、および正当なプライベートコミュニケーションの妨害。さらに、ホワイトリストに登録されたキーを持つ公開データベースを使用するさまざまな手法（DANE [RFC6698]など）により、ユーザーはこれらの種類の仲介者を検出できます。これらのユーザーは、サービスがブロックされているかのように動作する可能性があります。
If the intermediary is unable to decrypt the security protocol, then its blocking determinations for secure sessions can only be based on unprotected attributes, such as IP addresses, protocol IDs, port numbers, packet sizes, and packet timing. Some blocking systems today still attempt to block based on these attributes, for example by blocking TLS traffic to known proxies that could be used to tunnel through the blocking system.
仲介者がセキュリティプロトコルを復号化できない場合、セキュリティで保護されたセッションのブロックの決定は、IPアドレス、プロトコルID、ポート番号、パケットサイズ、パケットタイミングなどの保護されていない属性にのみ基づくことができます。現在、一部のブロッキングシステムは、これらの属性に基づいてブロックを試みます。たとえば、ブロッキングシステムを通過するトンネルに使用できる既知のプロキシへのTLSトラフィックをブロックします。
However, as the Telex project [Telex] recently demonstrated, if an endpoint cooperates with a relay in the network (e.g., a Telex station), it can create a TLS tunnel that is indistinguishable from legitimate traffic. For example, if an ISP used by a banking web site were to operate a Telex station at one of its routers, then a blocking system would be unable to distinguish legitimate encrypted banking traffic from Telex-tunneled traffic (potentially carrying content that would have been filtered).
ただし、Telexプロジェクト[Telex]が最近実証したように、エンドポイントがネットワーク内のリレー（たとえば、Telexステーション）と連携する場合、正当なトラフィックと区別できないTLSトンネルを作成する可能性があります。たとえば、銀行のWebサイトで使用されているISPがルーターの1つでTelexステーションを運用する場合、ブロッキングシステムは、正当な暗号化された銀行のトラフィックをTelexトンネルトラフィック（潜在的にフィルター済み）。
Thus, in principle in a blacklist system it is impossible to block tunneled traffic through an intermediary device without blocking all secure traffic from that system. (The only limitation in practice is the requirement for special software on the client.) Those who require that secure traffic be blocked from such sites risk blocking content that would be valuable to their users, perhaps impeding substantial economic activity. Conversely, those who are hosting a myriad of content have an incentive to see that law abiding content does not end up being blocked.
したがって、原則としてブラックリストシステムでは、そのシステムからのすべての安全なトラフィックをブロックせずに、仲介デバイスを通過するトンネルトラフィックをブロックすることは不可能です。 （実際の唯一の制限は、クライアント上の特別なソフトウェアの要件です。）安全なトラフィックをそのようなサイトからブロックすることを要求するユーザーは、ユーザーにとって貴重なコンテンツをブロックするリスクがあり、かなりの経済活動を妨げる可能性があります。逆に、無数のコンテンツをホストしている人は、コンテンツを順守する法律が最終的にブロックされないことを確認するインセンティブを持っています。
Governments and network operators should, however, take care not to encourage the use of insecure communications in the naming of security, as doing so will invariably expose their users to the various attacks that the security protocols were put in place to prevent.
ただし、政府とネットワークオペレーターは、セキュリティの命名において安全でない通信の使用を奨励しないように注意する必要があります。そうしないと、ユーザーがセキュリティプロトコルによって防止されたさまざまな攻撃に常にさらされるためです。
Some operators may assume that only blocking access to resources available via unsecure channels is sufficient for their purposes -- i.e., that the size of the user base that will be willing to use secure tunnels and/or special software to circumvent the blocking is low enough to make blocking via intermediaries worthwhile. Under that assumption, one might decide that there is no need to control secure traffic and thus that network-based blocking is an attractive option.
一部のオペレーターは、安全でないチャネルを介して利用可能なリソースへのアクセスをブロックするだけで十分であると想定する場合があります。つまり、安全なトンネルおよび/または特別なソフトウェアを使用してブロックを回避しようとするユーザーベースのサイズは十分に小さいと想定します。仲介者を経由してブロックする価値があります。その仮定の下で、安全なトラフィックを制御する必要がないと判断するかもしれません。そのため、ネットワークベースのブロッキングは魅力的なオプションです。
However, the longer such blocking systems are in place, the more likely it is that efficient and easy-to-use tunneling tools will become available. The proliferation of the Tor network, for example, and its increasingly sophisticated blocking-avoidance techniques demonstrate that there is energy behind this trend [Tor]. Thus, network-based blocking becomes less effective over time.
ただし、このようなブロッキングシステムが設置されている時間が長いほど、効率的で使いやすいトンネリングツールが使用可能になる可能性が高くなります。たとえば、Torネットワークの急増と、その高度化するブロッキング回避技術は、このトレンドの背後にエネルギーがあることを示しています[Tor]。したがって、ネットワークベースのブロッキングは、時間の経過とともに効果が低下します。
Network-based blocking is a key contributor to the arms race that has led to the development of such tools, the result of which is to create unnecessary layers of complexity in the Internet. Before content-based blocking became common, the next best option for network operators was port blocking, the widespread use of which has driven more applications and services to use ports (80 and 443 most commonly) that are unlikely to be blocked. In turn, network operators shifted to finer-grained content blocking over port 80, content providers shifted to encrypted channels, and operators began seeking to identify those channels (although doing so can be resource-prohibitive, especially if tunnel endpoints begin to change frequently). Because the premise of network-based blocking is that endpoints have incentives to circumvent it, this cat-and-mouse game is an inevitable by-product of this form of blocking.
ネットワークベースのブロッキングは、そのようなツールの開発につながった軍備競争への主要な貢献者であり、その結果、インターネットに不要な複雑なレイヤーが作成されます。コンテンツベースのブロックが一般的になる前は、ネットワークオペレーターの次善のオプションはポートブロックでした。これを広く使用することで、ブロックされる可能性の低いポート（最も一般的には80および443）を使用するアプリケーションやサービスが増えました。次に、ネットワークオペレーターはポート80経由でよりきめ細かいコンテンツブロッキングに移行し、コンテンツプロバイダーは暗号化されたチャネルに移行し、オペレーターはそれらのチャネルを特定しようとし始めました（ただし、そうすることで、特にトンネルエンドポイントが頻繁に変化し始める場合、リソースが大量に消費される可能性があります）。 。ネットワークベースのブロッキングの前提は、エンドポイントがそれを回避するインセンティブを持っていることなので、この猫とマウスのゲームは、この形式のブロッキングの必然的な副産物です。
One reason above all stands as an enormous challenge to network-based blocking: the Internet was designed with the premise that people will want to connect and communicate. IP will run on anything up to and including carrier pigeons [RFC1149]. It often runs atop TLS and has been made to run on other protocols that themselves run atop IP. Because of this fundamental layering approach, nearly any authorized avenue of communication can be used as a transport. This same "problem" permits communications to succeed in the most challenging of environments.
上記の理由の1つは、ネットワークベースのブロックに対する大きな課題であると考えられます。インターネットは、人々が接続して通信したいと思うことを前提に設計されています。 IPは、キャリアピジョン[RFC1149]を含むすべてのもので動作します。多くの場合、TLS上で実行され、IP上で実行される他のプロトコルで実行するように作られています。この基本的な階層化アプローチにより、許可されたほぼすべての通信手段をトランスポートとして使用できます。この同じ「問題」により、最も困難な環境でも通信が成功します。
In sum, network-based blocking is only effective in a fairly constrained set of circumstances. First, the traffic needs to flow through the network in such a way that the intermediary device has access to any communications it intends to block. Second, the blocking system needs an out-of-band mechanism to mitigate the risk of secure protocols being used to avoid blocking (e.g., human analysts identifying IP addresses of tunnel endpoints). If the network is sufficiently complex, or the risk of tunneling too high, then network-based blocking is unlikely to be effective, and in any case this type of blocking drives the development of increasingly complex layers of circumvention. Network-based blocking can be done without the cooperation of either endpoint to a communication, but it has the serious drawback of breaking end-to-end security assurances in some cases. The fact that network-based blocking is premised on this lack of cooperation results in arms races that increase the complexity of both application design and network design.
つまり、ネットワークベースのブロッキングは、かなり制約された一連の状況でのみ有効です。まず、トラフィックは、仲介デバイスがブロックしようとする通信にアクセスできるように、ネットワークを流れる必要があります。第2に、ブロッキングシステムは、ブロッキングを回避するために安全なプロトコルが使用されるリスクを軽減するために、帯域外メカニズムを必要とします（たとえば、人間の分析者がトンネルエンドポイントのIPアドレスを識別する）。ネットワークが十分に複雑である場合、またはトンネリングのリスクが高すぎる場合は、ネットワークベースのブロックが効果的である可能性は低く、いずれの場合も、このタイプのブロックはますます複雑な迂回の層の開発を促進します。ネットワークベースのブロッキングは、どちらかのエンドポイントが通信に協力しなくても実行できますが、場合によっては、エンドツーエンドのセキュリティ保証が破られるという重大な欠点があります。ネットワークベースのブロッキングがこの協力の欠如を前提としているという事実は、アプリケーション設計とネットワーク設計の両方の複雑さを増大させる軍拡競争をもたらします。
Internet applications often require or rely on support from common, global rendezvous services, including the DNS, certificate authorities, search engines, WHOIS databases, and Internet Route Registries. These services control or register the structure and availability of Internet applications by providing data elements that are used by application code. Some applications also have their own specialized rendezvous services. For example, to establish an end-to-end SIP call, the end-nodes (terminals) rely on presence and session information supplied by SIP servers.
インターネットアプリケーションは、DNS、認証局、検索エンジン、WHOISデータベース、インターネットルートレジストリなど、一般的なグローバルランデブーサービスのサポートを必要とするか、またはそれに依存していることがよくあります。これらのサービスは、アプリケーションコードで使用されるデータ要素を提供することにより、インターネットアプリケーションの構造と可用性を制御または登録します。一部のアプリケーションには、独自の専用ランデブーサービスもあります。たとえば、エンドツーエンドのSIPコールを確立するために、エンドノード（端末）は、SIPサーバーによって提供されるプレゼンスおよびセッション情報に依存します。
Global rendezvous services are comprised of generic technical databases intended to record certain facts about the network. The DNS, for example, stores information about which servers provide services for a given name, and the Resource Public Key Infrastructure (RPKI) stores information about which organizations have been allocated IP addresses. To offer specialized Internet services and applications, different people rely on these generic records in different ways. Thus, the effects of changes to the databases can be much more difficult to predict than, for example, the effect of shutting down a web server (which fulfills the specific purpose of serving web content).
グローバルランデブーサービスは、ネットワークに関する特定の事実を記録するための一般的な技術データベースで構成されています。たとえば、DNSは、特定の名前にサービスを提供するサーバーに関する情報を格納し、リソース公開キー基盤（RPKI）は、IPアドレスが割り当てられている組織に関する情報を格納します。専門のインターネットサービスとアプリケーションを提供するために、人々はさまざまな方法でこれらの一般的なレコードに依存しています。したがって、データベースへの変更の影響を予測するのは、たとえば、（Webコンテンツを提供する特定の目的を満たす）Webサーバーのシャットダウンの影響よりもはるかに難しい場合があります。
Although rendezvous services are discussed as a single category, the precise characteristics and implications of blocking each kind of rendezvous service are slightly different. This section provides examples to highlight these differences.
ランデブーサービスは単一のカテゴリとして説明されていますが、各種類のランデブーサービスをブロックすることの正確な特性と影響は少し異なります。このセクションでは、これらの違いを強調する例を示します。
In the case of government-initiated blocking, the operators of servers used to provide rendezvous service that are subject to a specific jurisdiction may be required to block or filter. Thus, it is possible for laws to be structured to result in blocking by imposing obligations on the operators of rendezvous services within a jurisdiction, either via direct government action or by allowing private actors to demand blocking (e.g., through lawsuits).
政府主導のブロッキングの場合、特定の管轄下にあるランデブーサービスの提供に使用されるサーバーのオペレーターは、ブロックまたはフィルタリングする必要がある場合があります。したがって、管轄区域内のランデブーサービスの運営者に、直接の政府の行動を介して、または（たとえば訴訟を通じて）ブロッキングを要求することを許可することによって義務を課すことによって、法律がブロッキングをもたらすように構造化される可能性があります。
The scope of blocking conducted by others will depend on which servers they can access. For example, network operators and enterprises may be capable of conducting blocking using their own DNS resolvers or application proxies within their networks, but not authoritative servers controlled by others.
他のユーザーが行うブロックの範囲は、他のユーザーがアクセスできるサーバーによって異なります。たとえば、ネットワークオペレーターと企業は、ネットワーク内で独自のDNSリゾルバーまたはアプリケーションプロキシを使用してブロックを実行できますが、他のユーザーによって制御されている権限のあるサーバーは実行できません。
However, if a service is hosted and operated within a jurisdiction where it is considered legitimate, then blocking access at a global rendezvous service (e.g., one within a jurisdiction where it is considered illegitimate) might deny services in jurisdictions where they are considered legitimate. This type of collateral damage is lessened when blocking is done at a local rendezvous server that only has local impact, rather than at a global rendezvous server with global impact.
ただし、サービスが正当と見なされる管轄区域内でホストおよび運用されている場合、グローバルランデブーサービス（たとえば、それが非合法と見なされる管轄区域内のサービス）でアクセスをブロックすると、正当と見なされる管轄区域でサービスが拒否される可能性があります。この種の副次的な被害は、グローバルに影響を与えるグローバルランデブーサーバーではなく、ローカルにのみ影響を与えるローカルランデブーサーバーでブロッキングを行うと軽減されます。
Blocking at a global rendezvous service can be overbroad if the resources blocked support multiple services, since blocking service can cause collateral damage to legitimate uses of other services. For example, a given address or domain name might host both legitimate services as well as services that some would desire to block.
ブロックされたサービスは他のサービスの正当な使用に付随的な損害を与える可能性があるため、ブロックされたリソースが複数のサービスをサポートしている場合、グローバルランデブーサービスでのブロックは過剰になる可能性があります。たとえば、特定のアドレスまたはドメイン名が、正当なサービスと、ブロックしたいサービスの両方をホストする場合があります。
The distributed nature of the Internet limits the efficacy of blocking based on rendezvous services. If the Internet community realizes that a blocking decision has been made and wishes to counter it, then local networks can "patch" the authoritative data that a global rendezvous service provides to avoid the blocking (although the development of DNSSEC and the RPKI are causing this to change by requiring updates to be authorized). In the DNS case, registrants whose names get blocked can relocate their resources to different names.
インターネットの分散された性質により、ランデブーサービスに基づくブロックの効果が制限されます。インターネットコミュニティがブロッキングの決定が行われたことを認識し、それを打ち消したい場合、ローカルネットワークはグローバルランデブーサービスが提供する信頼できるデータを「パッチ」してブロッキングを回避できます（ただし、DNSSECとRPKIの開発が原因です）更新の承認を要求することで変更する）。 DNSの場合、名前がブロックされた登録者は、リソースを別の名前に再配置できます。
Endpoints can also choose not to use a particular rendezvous service. They might switch to a competitor or use an alternate mechanism (for example, IP literals in URIs to circumvent DNS filtering).
エンドポイントは、特定のランデブーサービスを使用しないことも選択できます。競合他社に切り替えたり、別のメカニズムを使用したりする可能性があります（たとえば、DNSフィルタリングを回避するためのURIのIPリテラル）。
Blocking of global rendezvous services also has a variety of other implications that may reduce the stability, accessibility, and usability of the global Internet. Infrastructure-based blocking may erode the trust in the general Internet and encourage the development of parallel or "underground" infrastructures causing forms of Internet fragmentation, for example. This risk may become more acute as the introduction of security infrastructures and mechanisms such as DNSSEC and RPKI "hardens" the authoritative data -- including blocked names or routes -- that the existing infrastructure services provide. Those seeking to circumvent the blocks may opt to use less-secure but unblocked parallel services. As applied to the DNS, these considerations are further discussed in RFC 2826 [RFC2826], in the advisory [SAC-056] from ICANN's Security and Stability Advisory Committee (SSAC), and in the Internet Society's whitepaper on DNS filtering [ISOCFiltering], but they also apply to other global Internet resources.
グローバルランデブーサービスのブロックには、グローバルインターネットの安定性、アクセシビリティ、およびユーザビリティを低下させる可能性のある他のさまざまな影響もあります。インフラストラクチャベースのブロックは、一般的なインターネットの信頼を損ない、たとえば、インターネットの断片化の原因となる並列または「地下」インフラストラクチャの開発を促進する可能性があります。 DNSSECやRPKIなどのセキュリティインフラストラクチャやメカニズムの導入により、既存のインフラストラクチャサービスが提供する、ブロックされた名前やルートなどの信頼できるデータが「強化」されるため、このリスクはさらに深刻になる可能性があります。ブロックを回避しようとする人は、安全性は低いがブロックされていない並列サービスを使用することを選択できます。 DNSに適用されるこれらの考慮事項は、RFC 2826 [RFC2826]、ICANNのセキュリティおよび安定性諮問委員会（SSAC）からの諮問[SAC-056]、およびDNSフィルタリングに関するインターネット協会のホワイトペーパー[ISOCFiltering]でさらに議論されています。ただし、他のグローバルインターネットリソースにも適用されます。
Below we provide a few specific examples for routing, DNS, and WHOIS services. These examples demonstrate that for these types of rendezvous services (services that are often considered a global commons), jurisdiction-specific legal and ethical motivations for blocking can both have collateral effects in other jurisdictions and be circumvented because of the distributed nature of the Internet.
以下に、ルーティング、DNS、およびWHOISサービスの具体的な例をいくつか示します。これらの例は、これらの種類のランデブーサービス（グローバルコモンズと見なされることが多いサービス）の場合、管轄区域固有の法的および倫理的なブロッキングの動機が、他の管轄区域に付随的な影響を及ぼし、インターネットの分散された性質のために回避される可能性があることを示しています。
In 2008, Pakistan Telecom attempted to deny access to YouTube within Pakistan by announcing bogus routes for YouTube address space to peers in Pakistan. YouTube was temporarily denied service on a global basis as a result of a route leak beyond the Pakistani ISP's scope, but service was restored in approximately two hours because network operators around the world reconfigured their routers to ignore the bogus routes [RenesysPK]. In the context of SIDR and secure routing, a similar reconfiguration could theoretically be done if a resource certificate were to be revoked in order to block routing to a given network.
2008年、パキスタンテレコムは、YouTubeのアドレススペースの偽のルートをパキスタンのピアに発表することにより、パキスタン内のYouTubeへのアクセスを拒否しようとしました。パキスタンのISPの範囲を超えたルートリークの結果、YouTubeはグローバルベースで一時的にサービスを拒否されましたが、世界中のネットワークオペレーターがルーターを再構成して偽のルートを無視したため、サービスは約2時間で復旧しました[RenesysPK]。 SIDRおよび安全なルーティングのコンテキストでは、特定のネットワークへのルーティングをブロックするためにリソース証明書が取り消される場合、理論的には同様の再構成を行うことができます。
In the DNS realm, one of the recent cases of U.S. law enforcement seizing domain names involved RojaDirecta, a Spanish web site. Even though several of the affected domain names belonged to Spanish organizations, they were subject to blocking by the U.S. government because certain servers were operated in the United States.
DNSの領域では、米国の法執行機関がドメイン名を押収した最近の事件の1つに、スペインのWebサイトであるRojaDirectaが関係していました。影響を受けるドメイン名のいくつかはスペインの組織に属していましたが、特定のサーバーが米国で運用されていたため、米国政府によってブロックされました。
Government officials required the operators of the parent zones of a target name (e.g., "com" for "example.com") to direct queries for that name to a set of U.S.-government-operated name servers. Users of other services (e.g., email) under a target name would thus be unable to locate the servers providing services for that name, denying them the ability to access these services.
政府関係者は、ターゲット名（たとえば、「example.com」の場合は「com」）の親ゾーンのオペレーターに、その名前のクエリを米国政府が運営するネームサーバーのセットに送信するように要求しました。したがって、ターゲット名の下の他のサービス（電子メールなど）のユーザーは、その名前のサービスを提供するサーバーを見つけることができず、これらのサービスへのアクセスを拒否します。
Similar workarounds as those that were used in the Pakistan Telecom case are also available in the DNS case. If a domain name is blocked by changing authoritative records, network operators can restore service simply by extending TTLs on cached pre-blocking records in recursive resolvers, or by statically configuring resolvers to return unblocked results for the affected name. However, depending on the availability of valid signature data, these types of workarounds will not work with DNSSEC-signed data.
Pakistan Telecomのケースで使用された回避策と同様の回避策がDNSのケースでも利用可能です。信頼できるレコードを変更してドメイン名がブロックされた場合、ネットワークオペレーターは、再帰リゾルバーでキャッシュされたプレブロックレコードのTTLを拡張するか、影響を受ける名前のブロックされていない結果を返すようにリゾルバーを静的に構成することで、サービスを復元できます。ただし、有効な署名データの可用性に応じて、これらのタイプの回避策はDNSSEC署名付きデータでは機能しません。
The action of the Dutch authorities against the RIPE NCC, where RIPE was ordered to freeze the accounts of Internet resource holders, is of a similar character. By controlling the account holders' WHOIS information, this type of action limited the ability of the ISPs in question to manage their Internet resources. This example is slightly different from the others because it does not immediately impact the ability of ISPs to provide connectivity. While ISPs use (and trust) the WHOIS databases to build route filters or use the databases for trouble-shooting information, the use of the WHOIS databases for those purposes is voluntary. Thus, seizure of this sort may not have any immediate effect on network connectivity, but it may impact overall trust in the common infrastructure. It is similar to the other examples in that action in one jurisdiction can have broader effects, and in that the global system may encourage networks to develop their own autonomous solutions.
RIPEがインターネットリソースホルダーのアカウントを凍結するように命じられたRIPE NCCに対するオランダ当局の行動は、同様の性質のものです。アカウント所有者のWHOIS情報を制御することにより、この種のアクションは、問題のISPがインターネットリソースを管理する能力を制限しました。この例は、接続を提供するISPの機能にすぐには影響しないため、他の例とは少し異なります。 ISPはWHOISデータベースを使用（および信頼）してルートフィルターを構築したり、データベースをトラブルシューティング情報に使用したりしますが、これらの目的でのWHOISデータベースの使用は任意です。したがって、この種の差し押さえは、ネットワーク接続に直接影響を与えることはありませんが、共通インフラストラクチャへの全体的な信頼に影響を与える可能性があります。 1つの管轄区域での行動がより広い影響を与える可能性があること、およびグローバルシステムがネットワークに独自の自律的ソリューションの開発を奨励することができるという点で、それは他の例と同様です。
In summary, rendezvous-based blocking can sometimes be used to immediately block a target service by removing some of the resources it depends on. However, such blocking actions can have harmful side effects due to the global nature of Internet resources and the fact that many different application-layer services rely on generic, global databases for rendezvous purposes. The fact that Internet resources can quickly shift between network locations, names, and addresses, together with the autonomy of the networks that comprise the Internet, can mean that the effects of rendezvous-based blocking can be negated on short order in some cases. For some applications, rendezvous services are optional to use, not mandatory. Hence, they are only effective when the endpoint or the endpoint's network chooses to use them; they can be routed around by choosing not to use the rendezvous service or migrating to an alternative one. To adapt a quote by John Gilmore, "The Internet treats blocking as damage and routes around it".
要約すると、ランデブーベースのブロッキングは、依存するリソースの一部を削除することにより、ターゲットサービスをすぐにブロックするために使用できる場合があります。ただし、インターネットリソースのグローバルな性質と、多くの異なるアプリケーション層サービスがランデブーの目的で汎用のグローバルデータベースに依存しているという事実により、このようなブロックアクションは有害な副作用をもたらす可能性があります。インターネットリソースがネットワークの場所、名前、アドレス間ですばやく移動できるという事実は、インターネットを構成するネットワークの自律性とともに、ランデブーベースのブロッキングの影響が、場合によっては短期間で打ち消されることを意味します。一部のアプリケーションでは、ランデブーサービスの使用はオプションであり、必須ではありません。したがって、エンドポイントまたはエンドポイントのネットワークがそれらを使用することを選択した場合にのみ有効です。ランデブーサービスを使用しないことを選択するか、別のサービスに移行することで、それらを迂回させることができます。ジョン・ギルモアの引用を適合させるために、「インターネットはブロッキングを損傷として扱い、それを迂回する」。
Internet users and their devices constantly make decisions as to whether to engage in particular Internet communications. Users decide whether to click on links in suspect email messages; browsers advise users on sites that have suspicious characteristics; spam filters evaluate the validity of senders and messages. If the hardware and software making these decisions can be instructed not to engage in certain communications, then the communications are effectively blocked because they never happen.
インターネットユーザーとそのデバイスは、特定のインターネット通信に従事するかどうかを常に決定しています。ユーザーは、疑わしい電子メールメッセージのリンクをクリックするかどうかを決定します。ブラウザーは、疑わしい特性を持つサイトのユーザーにアドバイスします。スパムフィルターは、送信者とメッセージの有効性を評価します。これらの決定を行うハードウェアとソフトウェアが特定の通信を行わないように指示できる場合、通信は発生しないため、事実上ブロックされます。
There are several systems in place today that advise user systems about which communications they should engage in. As discussed above, several modern browsers consult with "Safe Browsing" services before loading a web site in order to determine whether the site could potentially be harmful. Spam filtering is one of the oldest types of filtering in the Internet; modern filtering systems typically make use of one or more "reputation" or "blacklist" databases in order to make decisions about whether a given message or sender should be blocked. These systems typically have the property that many filtering systems (browsers, Mail Transfer Agents (MTAs)) share a single reputation service. Even the absence of provisioned PTR records for an IP address may result in email messages not being accepted.
現在、ユーザーシステムにどの通信に関与する必要があるかを通知するいくつかのシステムがあります。上記のように、最近のいくつかのブラウザーは、サイトが潜在的に有害であるかどうかを判断するために、Webサイトをロードする前に「セーフブラウジング」サービスに問い合わせます。スパムフィルタリングは、インターネットで最も古いタイプのフィルタリングの1つです。最新のフィルタリングシステムは通常、特定のメッセージまたは送信者をブロックするかどうかを決定するために、1つ以上の「レピュテーション」または「ブラックリスト」データベースを利用します。これらのシステムには通常、多くのフィルタリングシステム（ブラウザ、メール転送エージェント（MTA））が単一のレピュテーションサービスを共有するという特性があります。 IPアドレスのプロビジョニングされたPTRレコードがない場合でも、電子メールメッセージが受け入れられない可能性があります。
In an endpoint-based blocking system, blocking actions are performed autonomously, by individual endpoints or their delegates. The effects of blocking are thus usually local in scope, minimizing the effects on other users or other, legitimate services.
エンドポイントベースのブロッキングシステムでは、ブロッキングアクションは、個々のエンドポイントまたはそのデリゲートによって自律的に実行されます。したがって、ブロックの影響は通常、ローカルな範囲であり、他のユーザーや他の正当なサービスへの影響を最小限に抑えます。
Endpoint-based blocking avoids some of the limitations of rendezvous-based blocking: while rendezvous-based blocking can only see and affect the rendezvous service at hand (e.g., DNS name resolution), endpoint-based blocking can potentially see into the entire application, across all layers and transactions. This visibility can provide endpoint-based blocking systems with a much richer set of information for making narrow blocking decisions. Support for narrow granularity depends on how the application protocol client and server are designed, however. A typical endpoint-based firewall application may have less ability to make fine-grained decisions than an application that does its own blocking (see [RFC7288] for further discussion).
エンドポイントベースのブロッキングは、ランデブーベースのブロッキングの一部の制限を回避します。ランデブーベースのブロッキングは、手元のランデブーサービス（DNS名前解決など）のみを参照して影響を与えることができますが、エンドポイントベースのブロッキングは、アプリケーション全体を潜在的に認識できます。すべてのレイヤーとトランザクションにわたって。この可視性により、エンドポイントベースのブロッキングシステムに、より狭いブロックの決定を行うためのより豊富な情報セットを提供できます。ただし、細分性のサポートは、アプリケーションプロトコルのクライアントとサーバーの設計方法によって異なります。典型的なエンドポイントベースのファイアウォールアプリケーションは、独自のブロッキングを行うアプリケーションよりもきめ細かい決定を行う能力が低い場合があります（詳細については[RFC7288]を参照）。
Endpoint-based blocking deals well with mobile adversaries. If a blocked service relocates resources or uses different resources, a rendezvous- or network-based blocking approach may not be able to affect the new resources (at least not immediately). A network-based blocking system may not even be able to tell whether the new resources are being used, if the previously blocked service uses secure protocols. By contrast, endpoint-based blocking systems can detect when a blocked service's resources have changed (because of their full visibility into transactions) and adjust blocking as quickly as new blocking data can be sent out through a reputation system.
エンドポイントベースのブロッキングは、モバイル攻撃者をうまく処理します。ブロックされたサービスがリソースを再配置するか、別のリソースを使用する場合、ランデブーベースまたはネットワークベースのブロックアプローチは、新しいリソースに影響を与えることができない場合があります（少なくともすぐには）。以前にブロックされたサービスが安全なプロトコルを使用している場合、ネットワークベースのブロックシステムは、新しいリソースが使用されているかどうかを判断できないこともあります。対照的に、エンドポイントベースのブロッキングシステムは、ブロックされたサービスのリソースが変更されたとき（トランザクションに対する完全な可視性のため）を検出し、レピュテーションシステムを通じて新しいブロッキングデータを送信できるのと同じくらい迅速にブロッキングを調整できます。
The primary challenge to endpoint-based blocking is that it requires the cooperation of endpoints. Where this cooperation is willing, this is a fairly low barrier, requiring only reconfiguration or software update. Where cooperation is unwilling, it can be challenging to enforce cooperation for large numbers of endpoints. That challenge is exacerbated when the endpoints are a diverse set of static, mobile, or visiting endpoints. If cooperation can be achieved, endpoint-based blocking can be much more effective than other approaches because it is so coherent with the Internet's architectural principles.
エンドポイントベースのブロッキングの主な課題は、エンドポイントの協力が必要なことです。この協力が可能である場合、これはかなり低い障壁であり、再構成またはソフトウェアの更新のみを必要とします。協力が望まれない場合、多数のエンドポイントに協力を実施することは困難な場合があります。エンドポイントが静的、モバイル、または訪問エンドポイントの多様なセットである場合、その課題はさらに悪化します。協力が実現できれば、エンドポイントベースのブロッキングはインターネットのアーキテクチャの原則と非常に一貫しているため、他のアプローチよりもはるかに効果的です。
Endpoint-based blocking is performed at one end of an Internet communication, and thus avoids the problems related to end-to-end security mechanisms that network-based blocking runs into and the challenges to global trust infrastructures that rendezvous-based blocking creates.
エンドポイントベースのブロッキングはインターネット通信の一端で実行されるため、ネットワークベースのブロッキングが実行されるエンドツーエンドのセキュリティメカニズムに関連する問題や、ランデブーベースのブロッキングが作成するグローバル信頼インフラストラクチャへの課題を回避します。
In this discussion of endpoint-based blocking, the focus has been on the consuming side of the end-to-end communication, mostly the client side of a client-server type connection. However, similar considerations apply to the content-producing side of end-to-end communications, regardless of whether that endpoint is a server in a client-server connection or a peer in a peer-to-peer type of connection.
エンドポイントベースのブロッキングに関するこの議論では、エンドツーエンド通信の消費側、主にクライアントサーバー型の接続のクライアント側に焦点が当てられてきました。ただし、エンドポイントがクライアント/サーバー接続のサーバーであるか、ピアツーピアタイプの接続のピアであるかに関係なく、エンドツーエンド通信のコンテンツ制作側にも同様の考慮事項が適用されます。
For instance, for blocking of web content, narrow targeting can be achieved through whitelisting methods like password authentication, whereby passwords are available only to authorized clients. For example, a web site might only make adult content available to users who provide credit card information, which is assumed to be a proxy for age.
たとえば、Webコンテンツをブロックする場合は、パスワード認証などのホワイトリスト方法を使用して、狭いターゲット設定を実現できます。これにより、許可されたクライアントのみがパスワードを使用できます。たとえば、Webサイトでは、年齢の代用と見なされるクレジットカード情報を提供するユーザーのみがアダルトコンテンツを利用できるようにする場合があります。
The fact that content-producing endpoints often do not take it upon themselves to block particular forms of content in response to requests from governments or other parties can sometimes motivate those latter parties to engage in blocking elsewhere within the Internet.
コンテンツを生成するエンドポイントが政府や他の当事者からの要求に応じて特定の形式のコンテンツをブロックすることを自分自身で受け取らないことが多いという事実は、それらの後者の当事者がインターネット内のどこか他の場所でブロックすることに動機を与えることがある。
If a service is to be blocked, the best way of doing that is to disable the service at the server endpoint.
サービスをブロックする場合、最善の方法はサーバーのエンドポイントでサービスを無効にすることです。
Out of the three design patterns, endpoint-based blocking is the least likely to cause collateral damage to Internet services or the overall Internet architecture. Endpoint-based blocking systems can potentially see into all layers involved in a communication, allowing blocking to be narrowly targeted and can minimize unintended consequences. Adversary mobility can be accounted for as soon as reputation systems are updated with new adversary information. One potential drawback of endpoint-based blocking is that it requires the endpoint's cooperation; implementing blocking at an endpoint when it is not in the endpoint's interest is therefore difficult to accomplish because the endpoint's user can disable the blocking or switch to a different endpoint.
3つの設計パターンのうち、エンドポイントベースのブロッキングは、インターネットサービスまたはインターネットアーキテクチャ全体に付随的な損害を引き起こす可能性が最も低いです。エンドポイントベースのブロッキングシステムは、通信に関与するすべてのレイヤーを潜在的に確認できるため、ブロッキングの対象を狭め、意図しない結果を最小限に抑えることができます。評判システムが新しい敵の情報で更新されるとすぐに、敵のモビリティを説明できます。エンドポイントベースのブロッキングの潜在的な欠点の1つは、エンドポイントの協力が必要なことです。エンドポイントのユーザーがブロッキングを無効にしたり、別のエンドポイントに切り替えたりすることができるため、エンドポイントの関心のないときにエンドポイントでブロッキングを実装することは困難です。
The primary security concern related to Internet service blocking is the effect that it has on the end-to-end security model of many Internet security protocols. When blocking is enforced by an intermediary with respect to a given communication, the blocking system may need to obtain access to confidentiality-protected data to make blocking decisions. Mechanisms for obtaining such access often require the blocking system to defeat the authentication mechanisms built into security protocols.
インターネットサービスブロッキングに関連する主要なセキュリティの問題は、多くのインターネットセキュリティプロトコルのエンドツーエンドのセキュリティモデルに及ぼす影響です。所定の通信に関して仲介者によってブロッキングが実施されている場合、ブロッキングシステムは、ブロッキングを決定するために、機密保護されたデータへのアクセスを取得する必要がある場合があります。このようなアクセスを取得するメカニズムでは、多くの場合、セキュリティプロトコルに組み込まれている認証メカニズムを無効にするために、ブロッキングシステムが必要です。
For example, some enterprise firewalls will dynamically create TLS certificates under a trust anchor recognized by endpoints subject to blocking. These certificates allow the firewall to authenticate as any web site, so that it can act as a man-in-the-middle on TLS connections passing through the firewall. This is not unlike an external attacker using compromised certificates to intercept TLS connections.
たとえば、一部のエンタープライズファイアウォールは、ブロッキングの対象となるエンドポイントによって認識されるトラストアンカーの下でTLS証明書を動的に作成します。これらの証明書により、ファイアウォールは任意のWebサイトとして認証されるため、ファイアウォールを通過するTLS接続で中間者として機能することができます。これは、侵害された証明書を使用してTLS接続を傍受する外部の攻撃者と同じです。
Modifications such as these obviously make the firewall itself an attack surface. If an attacker can gain control of the firewall or compromise the key pair used by the firewall to sign certificates, the attacker will have access to the unencrypted data of all current and recorded TLS sessions for all users behind that firewall, in a way that is undetectable to users. Besides, if the compromised key-pairs can be extracted from the firewall, all users, not only those behind the firewall, that rely on that public key are vulnerable.
これらのような変更は明らかにファイアウォール自体を攻撃面にします。攻撃者がファイアウォールを制御したり、ファイアウォールが証明書に署名するために使用するキーペアを侵害したりできる場合、攻撃者は、ファイアウォールの背後にあるすべてのユーザーの現在のすべての記録済みTLSセッションの暗号化されていないデータにアクセスできます。ユーザーには検出されません。さらに、侵害されたキーペアがファイアウォールから抽出できる場合、ファイアウォールの背後にいるユーザーだけでなく、その公開キーに依存するすべてのユーザーが脆弱になります。
We must also consider the possibility that a legitimate administrator of such a firewall could gain access to privacy-sensitive information, such as the bank accounts or health records of users who access such secure sites through the firewall. These privacy considerations motivate legitimate use of secure end-to-end protocols that often make it difficult to enforce granular blocking policies.
また、このようなファイアウォールの正当な管理者が、ファイアウォールを介してこのような安全なサイトにアクセスするユーザーの銀行口座や健康記録などのプライバシーに敏感な情報にアクセスできる可能性も考慮する必要があります。これらのプライバシーに関する考慮事項により、安全なエンドツーエンドプロトコルの正当な使用が促進され、きめ細かいブロックポリシーの適用が困難になることがよくあります。
When blocking systems are unable to inspect and surgically block secure protocols, it is tempting to completely block those protocols. For example, a web blocking system that is unable to inspect HTTPS connections might simply block any attempted HTTPS connection. However, since Internet security protocols are commonly used for critical services such as online commerce and banking, blocking these protocols would block access to these services as well, or worse, force them to be conducted over insecure communication.
ブロッキングシステムが安全なプロトコルを検査して外科的にブロックできない場合、それらのプロトコルを完全にブロックしたくなります。たとえば、HTTPS接続を検査できないWebブロッキングシステムは、試行されたHTTPS接続を単にブロックする可能性があります。ただし、インターネットセキュリティプロトコルはオンラインコマースやバンキングなどの重要なサービスで一般的に使用されるため、これらのプロトコルをブロックすると、これらのサービスへのアクセスもブロックされます。
Security protocols can, of course, also be used as mechanisms for blocking services. For example, if a blocking system can insert invalid credentials for one party in an authentication protocol, then the other end will typically terminate the connection based on the authentication failure. However, it is typically much simpler to simply block secure protocols than to exploit those protocols for service blocking.
もちろん、セキュリティプロトコルはサービスをブロックするメカニズムとしても使用できます。たとえば、ブロッキングシステムが認証プロトコルの一方のパーティに無効な資格情報を挿入できる場合、もう一方の端は通常、認証の失敗に基づいて接続を終了します。ただし、サービスのブロックにこれらのプロトコルを利用するよりも、安全なプロトコルを単にブロックする方が、通常ははるかに簡単です。
Filtering will continue to occur on the Internet. We conclude that, whenever possible, filtering should be done on the endpoint. Cooperative endpoints are most likely to have sufficient contextual knowledge to effectively target blocking; hence, such blocking minimizes unintended consequences. It is realistic to expect that at times filtering will not be done on the endpoints. In these cases, promptly informing the endpoint that blocking has occurred provides necessary transparency to redress any errors, particularly as they relate to any collateral damage introduced by errant filters.
フィルタリングは引き続きインターネットで行われます。可能な限り、エンドポイントでフィルタリングを行う必要があると結論付けます。協調エンドポイントは、ブロッキングを効果的に対象とするための十分なコンテキスト知識を持っている可能性が最も高いです。したがって、このようなブロックにより、意図しない結果が最小限に抑えられます。エンドポイントでフィルタリングが行われない場合があることを期待するのが現実的です。これらのケースでは、ブロッキングが発生したことをエンドポイントに迅速に通知することで、特にエラーが誤ったフィルターによって引き起こされた付随的な損傷に関連しているため、エラーを修正するために必要な透明性が提供されます。
Blacklist approaches are often a game of "cat and mouse", where those with the content move it around to avoid blocking. Or, the content may even be naturally mirrored or cached at other legitimate sites such as the Internet Archive Wayback Machine [Wayback]. At the same time, whitelists provide similar risks because sites that had "acceptable" content may become targets for "unacceptable content", and similarly, access to perfectly inoffensive and perhaps useful or productive content is unnecessarily blocked.
ブラックリストアプローチは、多くの場合、「猫とマウス」のゲームであり、コンテンツを持つユーザーは、ブロックを回避するために移動します。または、コンテンツがインターネットアーカイブウェイバックマシン[ウェイバック]などの他の正当なサイトに自然にミラーリングまたはキャッシュされる場合もあります。同時に、「許容できる」コンテンツを含むサイトが「許容できないコンテンツ」のターゲットになる可能性があるため、ホワイトリストも同様のリスクを提供します。同様に、完全に無害でおそらく有用または生産的なコンテンツへのアクセスが不必要にブロックされます。
From a technical perspective, there are no perfect or even good solutions -- there is only least bad. On that front, we posit that a hybrid approach that combines endpoint-based filtering with network filtering may prove least damaging. An endpoint may choose to participate in a filtering regime in exchange for the network providing broader unfiltered access.
技術的な観点からは、完全なソリューションや優れたソリューションはありません。その前に、エンドポイントベースのフィルタリングとネットワークフィルタリングを組み合わせたハイブリッドアプローチは、最も被害が少ないことが証明されると考えています。エンドポイントは、より広範なフィルタリングされていないアクセスを提供するネットワークと引き換えに、フィルタリング体制に参加することを選択できます。
Finally, we note that where filtering is occurring to address content that is generally agreed to be inappropriate or illegal, strong cooperation among service providers and governments may provide additional means to identify both the victims and the perpetrators through non-filtering mechanisms, such as partnerships with the finance industry to identify and limit illegal transactions.
最後に、不適切または違法であると一般的に合意されているコンテンツに対処するためにフィルタリングが行われている場合、サービスプロバイダーと政府間の強力な協力により、パートナーシップなどの非フィルタリングメカニズムを通じて被害者と加害者の両方を特定する追加の手段が提供される可能性があります金融業界と協力して、違法な取引を特定して制限します。
[asymmetry] John, W., Dusi, M., and K. Claffy, "Estimating routing symmetry on single links by passive flow measurements", Proceedings of the 6th International Wireless Communications and Mobile Computing Conference, IWCMC '10, DOI 10.1145/1815396.1815506, 2010, <http://www.caida.org/publications/papers/2010/ estimating_routing_symmetry/ estimating_routing_symmetry.pdf>.
[非対称]ジョン、W、デュシ、M、およびKクラフィー、「パッシブフロー測定による単一リンクのルーティング対称の推定」、第6回国際ワイヤレス通信およびモバイルコンピューティング会議の議事録、IWCMC '10、DOI 10.1145 / 1815396.1815506、2010、<http://www.caida.org/publications/papers/2010/見積もり_routing_symmetry /見積もり_routing_symmetry.pdf>。
[BlackLists14] Chachra, N., McCoy, D., Savage, S., and G. Voelker, "Empirically Characterizing Domain Abuse and the Revenue Impact of Blacklisting", Workshop on the Economics of Information Security 2014, <http://www.econinfosec.org/archive/weis2014/papers/ Chachra-WEIS2014.pdf>.
[BlackLists14] Chachra、N.、McCoy、D.、Savage、S。、およびG. Voelker、「ドメインの悪用とブラックリストの収益への影響を実験的に特徴付ける」、情報セキュリティの経済学に関するワークショップ2014、<http：// www.econinfosec.org/archive/weis2014/papers/ Chachra-WEIS2014.pdf>。
[BT-TPB] Meyer, D., "BT blocks The Pirate Bay", June 2012, <http://www.zdnet.com/ bt-blocks-the-pirate-bay-4010026434/>.
[BT-TPB]マイヤー、D。、「BTは海賊湾をブロックします」、2012年6月、<http://www.zdnet.com/ bt-blocks-the-pirate-bay-4010026434 />。
[CleanFeed] Clayton, R., "Failures in a Hybrid Content Blocking System", Fifth Privacy Enhancing Technologies Workshop, PET 2005, DOI 10.1007/11767831_6, 2005, <http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf>.
[CleanFeed] Clayton、R。、「Failures in a Hybrid Content Blocking System」、Fifth Privacy Enhancing Technologies Workshop、PET 2005、DOI 10.1007 / 11767831_6、2005、<http://www.cl.cam.ac.uk/~ rnc1 / cleanfeed.pdf>。
[GhostClickRIPE] RIPE NCC, "RIPE NCC Blocks Registration in RIPE Registry Following Order from Dutch Police", 2012, <http://www.ripe.net/internet-coordination/news/ about-ripe-ncc-and-ripe/ripe-ncc-blocks-registration-in-ripe-registry-following-order-from-dutch-police>.
[GhostClickRIPE] RIPE NCC、「オランダ警察からの命令に従ってRIPE NCCがRIPEレジストリへの登録をブロックする」、2012年、<http://www.ripe.net/internet-coordination/news/ about-ripe-ncc-and-ripe / ripe-ncc-blocks-registration-in-ripe-registry-following-order-from-dutch-police>。
[IN-OM-filtering] Citizen Lab, "Routing Gone Wild: Documenting upstream filtering in Oman via India", July 2012, <https://citizenlab.org/2012/07/routing-gone-wild/>.
[IN-OM-filtering] Citizen Lab、「Routing Gone Wild：Documentingアップストリームフィルタリングin India via India」、2012年7月、<https://citizenlab.org/2012/07/routing-gone-wild/>。
[ISOCFiltering] Internet Society, "DNS: Finding Solutions to Illegal On-line Activities", 2012, <http://www.internetsociety.org/what-we-do/issues/dns/ finding-solutions-illegal-line-activities>.
[IDOC Filtering] Internet Society、「DNS：Finding Solutions to Illegal Online Activities」、2012年、<http://www.internetsociety.org/what-we-do/issues/dns/finding-solutions-illegal-line-activities >。
[Malicious-Resolution] Dagon, D., Provos, N., Lee, C., and W. Lee, "Corrupted DNS Resolution Paths: The Rise of a Malicious Resolution Authority", 2008, <http://www.citi.umich.edu/u/provos/papers/ ndss08_dns.pdf>.
[Malicious-Resolution] Dagon、D.、Provos、N.、Lee、C。、およびW. Lee、「Corrupted DNS Resolution Paths：The Rise of a Malicious Resolution Authority」、2008、<http://www.citi .umich.edu / u / provos / papers / ndss08_dns.pdf>。
[Morris] Kehoe, B., "The Robert Morris Internet Worm", 1992, <http://groups.csail.mit.edu/mac/classes/6.805/articles/ morris-worm.html>.
[Morris] Kehoe、B。、「The Robert Morris Internet Worm」、1992、<http://groups.csail.mit.edu/mac/classes/6.805/articles/ morris-worm.html>。
[NW08] Marsan, C., "YouTube/Pakistan incident: Could something similar whack your site?", Network World, March 2008, <http://www.networkworld.com/article/2284273/software/ youtube-pakistan-incident--could-something-similar-whack-your-site-.html>.
[NW08]マルサン、C。、「YouTube /パキスタンの事件：同様のことがあなたのサイトを強打する可能性はありますか？」、ネットワークワールド、2008年3月、<http://www.networkworld.com/article/2284273/software/ youtube-pakistan-インシデント--could-something-similar-whack-your-site-.html>。
[Poort] Poort, J., Leenheer, J., van der Ham, J., and C. Dumitru, "Baywatch: Two approaches to measure the effects of blocking access to The Pirate Bay", Telecommunications Policy 38:383-392, DOI 10.1016/j.telpol.2013.12.008, 2014, <http://staff.science.uva.nl/~vdham/research/ publications/1401-Baywatch.pdf>.
[Poort] Poort、J.、Leenheer、J.、van der Ham、J。、およびC. Dumitru、「ベイウォッチ：海賊湾へのアクセスをブロックすることの影響を測定する2つのアプローチ」、通信ポリシー38：383-392 、DOI 10.1016 / j.telpol.2013.12.008、2014、<http://staff.science.uva.nl/~vdham/research/ Publications / 1401-Baywatch.pdf>。
[RenesysPK] Brown, M., "Pakistan hijacks YouTube", February 2008, <http://research.dyn.com/2008/02/ pakistan-hijacks-youtube-1/>.
[RenesysPK]ブラウンM.、「パキスタンがYouTubeをハイジャック」、2008年2月、<http://research.dyn.com/2008/02/ pakistan-hijacks-youtube-1 />。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, DOI 10.17487/RFC1149, April 1990, <http://www.rfc-editor.org/info/rfc1149>.
[RFC1149] Waitzman、D。、「鳥のキャリアでのIPデータグラムの送信に関する標準」、RFC 1149、DOI 10.17487 / RFC1149、1990年4月、<http://www.rfc-editor.org/info/rfc1149>。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, <http://www.rfc-editor.org/info/rfc2826>.
[RFC2826]インターネットアーキテクチャボード、「IAB Technical Comment on the Unique DNS Root」、RFC 2826、DOI 10.17487 / RFC2826、2000年5月、<http://www.rfc-editor.org/info/rfc2826>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<http：// www .rfc-editor.org / info / rfc2827>。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, <http://www.rfc-editor.org/info/rfc2979>.
[RFC2979] Freed、N。、「インターネットファイアウォールの動作と要件」、RFC 2979、DOI 10.17487 / RFC2979、2000年10月、<http://www.rfc-editor.org/info/rfc2979>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<http://www.rfc-editor.org/info/rfc3704 >。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC4084] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, May 2005, <http://www.rfc-editor.org/info/rfc4084>.
[RFC4084] Klensin、J。、「インターネット接続を説明するための用語」、BCP 104、RFC 4084、DOI 10.17487 / RFC4084、2005年5月、<http://www.rfc-editor.org/info/rfc4084>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, <http://www.rfc-editor.org/info/rfc4924>.
[RFC4924] Aboba、B.、Ed。 E. Davies、「Reflections on Internet Transparency」、RFC 4924、DOI 10.17487 / RFC4924、2007年7月、<http://www.rfc-editor.org/info/rfc4924>。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, DOI 10.17487/RFC4948, August 2007, <http://www.rfc-editor.org/info/rfc4948>.
[RFC4948] Andersson、L.、Davies、E.、and L. Zhang、 "Report from the IAB Workshop on Unwanted Traffic March 9-10、2006"、RFC 4948、DOI 10.17487 / RFC4948、2007年8月、<http：/ /www.rfc-editor.org/info/rfc4948>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, DOI 10.17487/RFC5782, February 2010, <http://www.rfc-editor.org/info/rfc5782>.
[RFC5782]レバイン、J。、「DNSブラックリストとホワイトリスト」、RFC 5782、DOI 10.17487 / RFC5782、2010年2月、<http://www.rfc-editor.org/info/rfc5782>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<http://www.rfc-editor.org/info/rfc6480> 。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<http：/ /www.rfc-editor.org/info/rfc6698>。
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>.
[RFC6943] Thaler、D。、編、「セキュリティ上の目的での識別子比較の問題」、RFC 6943、DOI 10.17487 / RFC6943、2013年5月、<http://www.rfc-editor.org/info/rfc6943>。
[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>。
[RojaDirecta] Masnick, M., "Homeland Security Seizes Spanish Domain Name That Had Already Been Declared Legal", 2011, <http://www.techdirt.com/articles/20110201/10252412910/ homeland-security-seizes-spanish-domain-name-that-had-already-been-declared-legal.shtml>.
[RojaDirecta] Masnick、M。、「国土安全保障省はすでに法的に宣言されていたスペインのドメイン名を奪取する」、2011年、<http://www.techdirt.com/articles/20110201/10252412910/ homeland-security-seizes-spanish- domain-name-that-had-already-been-declared-legal.shtml>。
[SAC-056] ICANN SSAC, "SSAC Advisory on Impacts of Content Blocking via the Domain Name System", October 2012, <http://www.icann.org/en/groups/ssac/documents/ sac-056-en.pdf>.
[SAC-056] ICANN SSAC、「ドメインネームシステムによるコンテンツブロッキングの影響に関するSSACアドバイザリ」、2012年10月、<http://www.icann.org/en/groups/ssac/documents/ sac-056-en .pdf>。
[SafeBrowsing] Google, "Safe Browsing API", 2012, <https://developers.google.com/safe-browsing/>.
[SafeBrowsing] Google、「Safe Browsing API」、2012、<https://developers.google.com/safe-browsing/>。
[Takedown08] Moore, T. and R. Clayton, "The Impact of Incentives on Notice and Take-down", Workshop on the Economics of Information Security 2008, <http://www.econinfosec.org/archive/weis2008/papers/ MooreImpact.pdf>.
[Takedown08] Moore、T. and R. Clayton、 "The Impact of Incentives on Notice and Takedown"、Workshop on the Economics of Information Security 2008、<http://www.econinfosec.org/archive/weis2008/papers / MooreImpact.pdf>。
[Telex] Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman, "Telex: Anticensorship in the Network Infrastructure", <https://telex.cc/>.
[Telex] Wustrow、E.、Wolchok、S.、Goldberg、I。、およびJ. Halderman、「Telex：Anticensorship in the Network Infrastructure」、<https://telex.cc/>。
[Tor] "Tor Project: Anonymity Online", <https://www.torproject.org/>.
[Tor]「Tor Project：Anonymity Online」、<https://www.torproject.org/>。
[Wayback] "Internet Archive: Wayback Machine", <http://archive.org/web/>.
[ウェイバック]「インターネットアーカイブ：ウェイバックマシン」、<http://archive.org/web/>。
IAB Members at the Time of Approval
承認時のIABメンバー
Jari Arkko Mary Barnes Marc Blanchet Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Brian Trammell Suzanne Woolf
ジャリアルコメアリーバーンズマルクブランシェラルフドロムステッドハーディジョーヒルデブランドラスハウズリーエリックノールマークロバートスパークスアンドリューサリバンデイブターラーブライアントラメルスザンヌウルフ
Acknowledgments
謝辞
Thanks to the many reviewers who provided helpful comments, especially Bill Herrin, Eliot Lear, Patrik Faltstrom, Pekka Savola, and Russ White. NLnet Labs is also acknowledged as Olaf Kolkman's employer during most of this document's development.
特にBill Herrin、Eliot Lear、Patrik Faltstrom、Pekka Savola、Russ Whiteなど、役立つコメントを寄せてくれた多くのレビューアに感謝します。 NLnet Labsは、このドキュメントの開発の大部分において、Olaf Kolkmanの雇用主としても認められています。
Authors' Addresses
著者のアドレス
Richard Barnes Mozilla Suite 300 650 Castro Street Mountain View, CA 94041 United States
Richard Barnes Mozilla Suite 300 650 Castro Street Mountain View、CA 94041アメリカ合衆国
Email: rlb@ipv.sx
Alissa Cooper Cisco 707 Tasman Drive Milpitas, CA 95035 United States
Alissa Cooper Cisco 707 Tasman Drive Milpitas、CA 95035アメリカ合衆国
Email: alcoop@cisco.com
Olaf Kolkman Internet Society
オラフコルクマンインターネット協会
Email: kolkman@isoc.org
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 United States
Dave Thalerマイクロソフトワンマイクロソフトウェイレドモンド、ワシントン州98052アメリカ合衆国
Email: dthaler@microsoft.com
Erik Nordmark Arista
エリックノードマークアリスタ
Email: nordmark@arista.com