Technical Considerations for Internet Service Blocking and Filtering
draft-iab-filtering-considerations-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7754.
|
|
|---|---|---|---|
| Authors | Richard Barnes , Alissa Cooper , Olaf Kolkman | ||
| Last updated | 2013-02-23 | ||
| Replaces | draft-barnes-blocking-considerations | ||
| RFC stream | Internet Architecture Board (IAB) | ||
| Formats | |||
| Additional resources | |||
| Stream | IAB state | Active IAB Document | |
| Consensus boilerplate | Unknown | ||
| IAB shepherd | (None) |
draft-iab-filtering-considerations-02
Internet Architecture Board R. Barnes
Internet-Draft BBN Technologies
Intended status: Informational A. Cooper
Expires: August 27, 2013 CDT
O. Kolkman
NLnet Labs
February 23, 2013
Technical Considerations for Internet Service Blocking and Filtering
draft-iab-filtering-considerations-02.txt
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 allegedly illegal
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 content blocking and filtering in terms of their
alignment with the overall Internet architecture. In general, the
approach to content 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 illegal communications.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2013.
Copyright Notice
Barnes, et al. Expires August 27, 2013 [Page 1]
Internet-Draft Filtering Considerations February 2013
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architectural Principles . . . . . . . . . . . . . . . . . . . 4
2.1. End-to-End Connectivity and "Transparency" . . . . . . . . 4
2.2. Layering . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Distribution and Mobility . . . . . . . . . . . . . . . . 6
2.4. Locality and Autonomy . . . . . . . . . . . . . . . . . . 6
3. Examples of Blocking . . . . . . . . . . . . . . . . . . . . . 7
4. Blocking Design Patterns . . . . . . . . . . . . . . . . . . . 9
4.1. Network-Based Blocking . . . . . . . . . . . . . . . . . . 10
4.1.1. Interaction with Architectural Principles . . . . . . 11
4.1.2. Circumvention . . . . . . . . . . . . . . . . . . . . 11
4.2. Infrastructure-Based Blocking . . . . . . . . . . . . . . 14
4.3. Endpoint-Based Blocking . . . . . . . . . . . . . . . . . 16
5. Summary of Trade-offs . . . . . . . . . . . . . . . . . . . . 18
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Informative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Barnes, et al. Expires August 27, 2013 [Page 2]
Internet-Draft Filtering Considerations February 2013
1. Introduction
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 arguably undesirable communications. 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 undesirable communications.
Efforts to restrict or deny access to Internet resources have evolved
over time. As noted in [RFC4084], some Internet service providers
impose restrictions on 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. Increasingly, however, both governmental
and private sector entities are seeking to block or filter access to
certain content, traffic, or communications without the knowledge or
agreement of affected users. Where these entities do not directly
control networks themselves, they commonly aim to make use of
intermediary systems to effectuate the blocking or filtering.
Entities may seek to block or filter Internet content for a diversity
of reasons, including defending against security threats, restricting
access to content thought to be objectionable, and preventing
nefarious or illegal activity. While blocking and filtering remain
highly contentious in many cases, the desire to restrict 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 effectuated 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.
This document aims to clarify the technical implications and trade-
offs of various blocking strategies and to identify the potential for
different strategies to come into conflict with the Internet's
architecture, or potentially cause harmful side effects ("collateral
damage"). Blocking is principally taken up (whether voluntarily or
not) by three types of entities:
Hoffman Expires December 19, 2015 [Page 11]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
This element appears as a child element of: <reference>
(Section 2.40).
Content model:
In any order:
o Text
o <bcp14> elements (Section 2.9)
o <cref> elements (Section 2.16)
o <em> elements (Section 2.22)
o <eref> elements (Section 2.24)
o <iref> elements (Section 2.27)
o <relref> elements (Section 2.44)
o <spanx> elements (Section 3.7)
o <strong> elements (Section 2.50)
o <sub> elements (Section 2.51)
o <sup> elements (Section 2.52)
o <tt> elements (Section 2.62)
o <xref> elements (Section 2.66)
2.4. <area>
Provides information about the IETF area to which this document
relates (currently not used when generating documents).
The value ought to be either the full name or the abbreviation of one
of the IETF areas as listed on <http://www.ietf.org/iesg/area.html>.
The list at the time that this document is being published is:
"Applications", "app", "General", "gen", "Internet", "int",
"Operations and Management", "ops", "Real-time Applications and
Infrastructure", "rai", "Routing", "rtg", "Security", "sec",
"Transport", "tsv".
This element appears as a child element of: <front> (Section 2.26).
Hoffman Expires December 19, 2015 [Page 12]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
Content model: only text content.
2.5. <artwork>
This element allows the inclusion of "artwork" into the document.
<artwork> provides full control of horizontal whitespace and line
breaks, and thus is used for a variety of things, such as diagrams
("line art") and protocol unit diagrams.
Alternatively, the "src" attribute allows referencing an external
graphics file, such as a vector drawing in SVG or a bitmap graphic
file, using a URI. In this case, the textual content acts as
fallback for output representations that do not support graphics, and
thus ought to contain either a "line art" variant of the graphics, or
otherwise prose that describes the included image in sufficient
detail.
If the artwork includes either "&" or "<" characters, or the string
"]]>" those characters need to be encoded using escaping or CDATA
block(s); see <sourcecode> for a fuller description of these
solutions.
In [XML2RFCv2], the <artwork> element was also used for source code
and formal languages; in v3, this is now done with <sourcecode>.
There are at least five ways to include SVG in artwork in Internet
Drafts:
o Inline, by including all of the SVG in the content of the element,
such as: <artwork type="svg"><svg xmlns...">
o Inline, but using XInclude (see Appendix B.1), such as: <artwork
type="svg"><xi:include href=...>
o As a data: URI, such as: <artwork type="svg" src="data:image/
svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3...">
o As a URI to an external entity, such as: <artwork type="svg"
src="http://www.example.com/...">
o As a local file, such as: <artwork type="svg" src="diagram12.svg">
The use of SVG in Internet Drafts and RFCs is covered in much more
detail in [SVGforRFCs].
The above methods for inclusion of SVG art can also be used for
including text artwork, but using a data: URI is probably confusing
for text artwork.
Hoffman Expires December 19, 2015 [Page 13]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
Formatters that do pagination should attempt to keep artwork on a
single page. This is to prevent artwork that is split across pages
from looking like two separate pieces of artwork.
This element appears as a child element of: <aside> (Section 2.6),
<blockquote> (Section 2.10), <dd> (Section 2.18), <figure>
(Section 2.25), <li> (Section 2.29), <section> (Section 2.46), <td>
(Section 2.56), and <th> (Section 2.58).
Content model:
Either:
Text
Or:
<svg> elements (Section 2.67)
2.5.1. 'align' attribute
Controls whether the artwork appears left justified (default),
centered, or right justified.
Allowed values:
o "left" (default)
o "center"
o "right"
2.5.2. 'alt' attribute
Alternative text description of the artwork (which is more than just
a summary or caption). When the art comes from the "src" attribute,
and the format of that artwork supports alternate text, the
alternative text comes from the text of the artwork itself, not from
this attribute. The contents of this attribute are important to
readers who are visually impaired, as well as those reading on
devices that cannot show the artwork well, or at all.
2.5.3. 'anchor' attribute
Document-wide unique identifier for this artwork.
Hoffman Expires December 19, 2015 [Page 14]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.5.4. 'height' attribute
Deprecated.
2.5.5. 'name' attribute
A filename suitable for the contents (such as for extraction to a
local file). This attribute can be helpful for other kinds of tools
(such as automated syntax checkers which work by extracting the
artwork). Note that the "name" attribute does not need to be unique
for artwork elements in a document. If multiple artwork elements
have the same name attribute, a processing tool might assume that the
elements are all fragments of a single file, and the tool can collect
those fragments for later processing.
2.5.6. 'src' attribute
The URI reference of a graphics file ([RFC3986]), or the name of a
file on the local disk. This can be a "data" URI ([RFC2397]) that
contains the contents of the graphics file. Note that the inclusion
of art with the "src" attribute depends on the capabilities of the
processing tool reading the XML document. Tools need to be able to
handle the file: URI, and should be able to handle http: and https:
URIs as well. The prep tool will be able to handle reading the "src"
attribute.
If no URI scheme is given in the attribute, the attribute is
considered to be a local file name. Processing tools must be careful
to not accept dangerous values for the filename, particularly those
that contain absolute references outside the current directory.
In some cases, the prep tool may remove the "src" attribute after
processing its value. See [PREPTOOL] for a description of this.
It is an error to have both a "src" attribute and content in the
<artwork> element.
2.5.7. 'type' attribute
Specifies the type of the artwork. The value of this attribute is
free text with certain values designated as preferred.
The preferred values for <artwork> types are:
o ascii-art
o binary-art
Hoffman Expires December 19, 2015 [Page 15]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
o call-flow
o hex-dump
o svg
The RFC Editor will maintain a complete list of the preferred values
on its web site, and that list is expected to be updated over time.
Thus, a consumer of v3 XML should not cause a failure when it
encounters an unexpected type.
2.5.8. 'width' attribute
Deprecated.
2.5.9. 'xml:space' attribute
Deprecated.
2.6. <aside>
This element is a container for content that is semantically less
important or tangential to the content that surrounds it.
This element appears as a child element of: <section> (Section 2.46).
Content model:
In any order:
o <artwork> elements (Section 2.5)
o <dl> elements (Section 2.20)
o <figure> elements (Section 2.25)
o <iref> elements (Section 2.27)
o <list> elements (Section 3.4)
o <ol> elements (Section 2.34)
o <t> elements (Section 2.53)
o <table> elements (Section 2.54)
o <ul> elements (Section 2.63)
Hoffman Expires December 19, 2015 [Page 16]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.6.1. 'anchor' attribute
Document-wide unique identifier for this aside.
2.7. <author>
Provides information about a document's author. This is used both
for the document itself (at the beginning of the document) and for
referenced documents.
The <author> elements contained within the document's <front> element
are used to fill the boilerplate, and also to generate the "Author's
Address" section (see [RFC7322]).
Note that an "author" can also be just an organization (by not
specifying any of the name attributes, but adding the <organization>
child element).
Furthermore, the "role" attribute can be used to mark an author as
"editor". This is reflected both on the front page and in
bibliographical references. Note that this specification does not
define a precise meaning for the term "editor".
See Section "Authors vs. Contributors" of [RFCPOLICY] for more
information.
This element appears as a child element of: <front> (Section 2.26).
Content model:
In this order:
1. One optional <organization> element (Section 2.35)
2. One optional <address> element (Section 2.2)
2.7.1. 'asciiFullname' attribute
The ASCII equivalent of the author's full name.
2.7.2. 'asciiInitials' attribute
The ASCII equivalent of the author's intials.
2.7.3. 'asciiSurname' attribute
The ASCII equivalent of the author's surname.
Hoffman Expires December 19, 2015 [Page 17]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.7.4. 'fullname' attribute
The full name (used in the automatically generated "Author's Address"
section).
2.7.5. 'initials' attribute
Author initials (used on the front page and in references).
The value contains one or more initials, each followed by a period.
Initials should be provided as a whitespace separated list of pairs
of a letter and a dot.
2.7.6. 'role' attribute
Specifies the role the author had in creating the document.
Allowed values:
o "editor"
2.7.7. 'surname' attribute
The author's surname (used on the front page and in references).
2.8. <back>
Contains the "back" part of the document: the references and
appendices. In <back>, <section> elements indicate appendices.
This element appears as a child element of: <rfc> (Section 2.45).
Content model:
In this order:
1. Optional <displayreference> elements (Section 2.19)
2. Optional <references> elements (Section 2.42)
3. Optional <section> elements (Section 2.46)
2.9. <bcp14>
Marks text that are phrases defined in BCP 14 such as "MUST", "SHOULD
NOT", and so on. When shown in some of the output representations,
the text in this element might be highlighted. The use of this
element is optional.
Hoffman Expires December 19, 2015 [Page 18]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
This element is only to be used around the actual phrase from BCP 14,
not the full definition of a requirement. For example, it is correct
to say "The packet <bcp14>MUST</bcp14> be dropped.", but it not
correct to say "<bcp14>The packet MUST be dropped.</bcp14>".
This element appears as a child element of: <annotation>
(Section 2.3), <blockquote> (Section 2.10), <dd> (Section 2.18), <dt>
(Section 2.21), <em> (Section 2.22), <li> (Section 2.29), <preamble>
(Section 3.6), <refcontent> (Section 2.39), <strong> (Section 2.50),
<sub> (Section 2.51), <sup> (Section 2.52), <t> (Section 2.53), <td>
(Section 2.56), <th> (Section 2.58), and <tt> (Section 2.62).
Content model: only text content.
2.10. <blockquote>
Specifies a block of text is a quotation.
This element appears as a child element of: <section> (Section 2.46).
Content model:
Either:
In any order, but at least one of:
* <artwork> elements (Section 2.5)
* <dl> elements (Section 2.20)
* <figure> elements (Section 2.25)
* <ol> elements (Section 2.34)
* <sourcecode> elements (Section 2.48)
* <t> elements (Section 2.53)
* <ul> elements (Section 2.63)
Or:
In any order, but at least one of:
Hoffman Expires December 19, 2015 [Page 19]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
* Text
* <bcp14> elements (Section 2.9)
* <cref> elements (Section 2.16)
* <em> elements (Section 2.22)
* <eref> elements (Section 2.24)
* <iref> elements (Section 2.27)
* <relref> elements (Section 2.44)
* <strong> elements (Section 2.50)
* <sub> elements (Section 2.51)
* <sup> elements (Section 2.52)
* <tt> elements (Section 2.62)
* <xref> elements (Section 2.66)
2.10.1. 'anchor' attribute
Document-wide unique identifier for this quotation.
2.10.2. 'cite' attribute
The source of the citation. This must be a URI. If the quotedFrom
attribute is given, this URI will be used by processing tools as the
link for the text of that attribute.
2.10.3. 'quotedFrom' attribute
Name of person or document the text in this element is quoted from.
A formatter should render this as visible text at the end of the
quotation.
2.11. <boilerplate>
Holds the boilerplate text for the document. This section is filled
in by the prep tool.
This element appears as a child element of: <front> (Section 2.26).
Hoffman Expires December 19, 2015 [Page 20]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
Content model:
One or more <section> elements (Section 2.46)
2.12. <br>
Indicates that a line break should be inserted in the generated
output by a formatting tool. Multiple successive instances of this
element do not cause blank lines to appear in the output, and is thus
not useful.
This element appears as a child element of: <td> (Section 2.56), and
<th> (Section 2.58).
Content model: this element does not have any contents.
2.13. <city>
Gives the city name in a postal address.
This element appears as a child element of: <postal> (Section 2.37).
Content model: only text content.
2.13.1. 'ascii' attribute
The ASCII equivalent of the city name.
2.14. <code>
Gives the postal region code.
This element appears as a child element of: <postal> (Section 2.37).
Content model: only text content.
2.14.1. 'ascii' attribute
The ASCII equivalent of the postal code.
2.15. <country>
Gives the country name or code in a postal address.
This element appears as a child element of: <postal> (Section 2.37).
Content model: only text content.
Hoffman Expires December 19, 2015 [Page 21]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.15.1. 'ascii' attribute
The ASCII equivalent of the country name.
2.16. <cref>
Represents a comment.
Comments can be used in a document while it is work-in-progress.
They might appear either inline and visually highlighted, at the end
of the document, or not at all, depending on the formatting tool.
This element appears as a child element of: <annotation>
(Section 2.3), <blockquote> (Section 2.10), <c> (Section 3.1), <dd>
(Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li>
(Section 2.29), <name> (Section 2.32), <postamble> (Section 3.5),
<preamble> (Section 3.6), <strong> (Section 2.50), <sub>
(Section 2.51), <sup> (Section 2.52), <t> (Section 2.53), <td>
(Section 2.56), <th> (Section 2.58), <tt> (Section 2.62), and <ttcol>
(Section 3.9).
Content model:
In any order:
o Text
o <em> elements (Section 2.22)
o <eref> elements (Section 2.24)
o <relref> elements (Section 2.44)
o <strong> elements (Section 2.50)
o <sub> elements (Section 2.51)
o <sup> elements (Section 2.52)
o <tt> elements (Section 2.62)
o <xref> elements (Section 2.66)
2.16.1. 'anchor' attribute
Document-wide unique identifier for this comment.
Hoffman Expires December 19, 2015 [Page 22]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.16.2. 'display' attribute
Suggests whether or not the the comment should be displayed by
formatting tools. This might be set to "false" if you want to keep a
comment in a document after the contents of the comment have already
been dealt with.
Allowed values:
o "true" (default)
o "false"
2.16.3. 'source' attribute
Holds the "source" of a comment, such as the name or the initials of
the person who made the comment.
2.17. <date>
Provides information about the publication date.
Note that this element is used both for the boilerplate of the
document being produced, and also inside bibliographic references
that use the <front> element.
In the boilerplate case, it defines the date of publication for the
current document (Internet Draft or RFC). When producing Internet-
Drafts, the prep tool uses this date to compute the expiration date
(see [IDGUIDE]). When one or more of "year", "month", or "day" are
left out, the prep tool will attempt to use the current system date
if the attributes that are present are consistent with that date.
Also in the first case, that month names, if given, need to match the
full English month name: "January", "February", "March", "April",
"May, "June", "July", "August", "September", "October", "November",
or "December".
When the prep tool is used to create Internet Drafts, it will reject
a submitted Internet Draft that has a <date> element in the
boilerplate for itself that is anything other than today. That is,
the tool will not allow a submitter to specify a date other than the
day of submission. To avoid this problem, authors might simply not
include a <date> element in the boilerplate.
In the case of bibliographic references, the date information can
have prose text for the month or year. For example, vague dates
(year="ca. 2000"), date ranges (year="2012-2013"), non-specific
Hoffman Expires December 19, 2015 [Page 23]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
months (month="Second quarter") and so on, are allowed.
This element appears as a child element of: <front> (Section 2.26).
Content model: this element does not have any contents.
2.17.1. 'day' attribute
In the "boilerplate" case: the day of publication; this is a number.
Otherwise: an indication of the publication day, with the format not
being restricted.
2.17.2. 'month' attribute
In the "boilerplate" case: the month of publication; this is the
English name of the month. Otherwise: an indication of the
publication month, with the format not being restricted.
2.17.3. 'year' attribute
In the "boilerplate" case: the year of publication; this is a number
(usually four-digit). Otherwise: an indication of the publication
year, with the format not being restricted.
2.18. <dd>
The definition part of an entry in a definition list.
This element appears as a child element of: <dl> (Section 2.20).
Content model:
Either:
In any order, but at least one of:
* <artwork> elements (Section 2.5)
* <dl> elements (Section 2.20)
* <figure> elements (Section 2.25)
* <ol> elements (Section 2.34)
* <sourcecode> elements (Section 2.48)
Hoffman Expires December 19, 2015 [Page 24]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
* <t> elements (Section 2.53)
* <ul> elements (Section 2.63)
Or:
In any order, but at least one of:
* Text
* <bcp14> elements (Section 2.9)
* <cref> elements (Section 2.16)
* <em> elements (Section 2.22)
* <eref> elements (Section 2.24)
* <iref> elements (Section 2.27)
* <relref> elements (Section 2.44)
* <strong> elements (Section 2.50)
* <sub> elements (Section 2.51)
* <sup> elements (Section 2.52)
* <tt> elements (Section 2.62)
* <xref> elements (Section 2.66)
2.18.1. 'anchor' attribute
Document-wide unique identifier for this definition.
2.19. <displayreference>
This element gives a mapping between the anchor of a reference and a
name that will be displayed instead. This allows authors to display
more mneumonic anchor names for automatically-included references.
For example, if the reference uses the anchor "RFC6949", the
following would cause that anchor in the body of displayed documents
to be "RFC-dev":
Hoffman Expires December 19, 2015 [Page 25]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
Barnes, et al. Expires August 27, 2013 [Page 3]
Internet-Draft Filtering Considerations February 2013
1. Operators of networks (including enterprises)
2. Operators of infrastructure services (for naming, routing, and
other core Internet functions)
3. Operators of endpoints (including end users and application
providers)
Examples of blocking or attempted blocking using the DNS, HTTP
proxies, spam filters, and RPKI manipulation are used to illustrate
each category's properties.
Filtering may be considered legal, illegal, ethical, or unethical in
different places, at different times, and by different parties. This
document is intended for an audience of entities that are filtering
or are considering filtering and who 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.
In [SAC-056], ICANN's Security and Stability Advisory Committee
(SSAC) assessed the aspects of blocking using the DNS. This document
attempts to take a broader perspective on blocking and filtering and
genaralizes from some of SSAC's findings.
2. Architectural Principles
To understand the implications of different blocking strategies, it
is important to understand the key principles that have informed the
design of the Internet. While much of this ground has been well trod
before, this section highlights four architectural principles that
have a direct impact on the viability of content blocking: end-to-end
connectivity and "transparency," layering, distribution and mobility,
and locality and autonomy.
2.1. End-to-End Connectivity and "Transparency"
The end-to-end principle is "the core architectural guideline of the
Internet" [RFC3724]. Adherence to the principle of vesting endpoints
with the functionality to accomplish end-to-end tasks results in a
"transparent" network in which packets are not filtered or
Barnes, et al. Expires August 27, 2013 [Page 4]
Internet-Draft Filtering Considerations February 2013
transformed en route [RFC2775]. This transparency in turn is a key
requirement for providing end-to-end security features on the
network. Modern security mechanisms that rely on trusted hosts
communicating via a secure channel without intermediary interference
enable the network to support e-commerce, confidential communication,
and an array of other similar uses.
The end-to-end principle is fundamental for Internet security, and
the foundation on which Internet security protocols are built.
Protocols such as TLS and IPsec [RFC5246][RFC4301] are designed to
ensure that each endpoint of the communication knows the identity of
the other endpoint, 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.
Some blocking strategies require intermediaries to insert themselves
within the end-to-end communications path (network-based web
filtering systems, for example), potentially breaking security
properties of Internet protocols. In these cases it can be difficult
or impossible for endpoints to distinguish between attackers and
"authorized" entities conducting blocking.
2.2. Layering
"Different Players on Different Layers."
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 entities. 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. As a consequence of the end-to-end principle, 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.
As a result of this structure, actions taken at one layer can affect
functionality or applications at higher layers. For example,
manipulating routing or naming functions to restrict access to a
narrow set of resources via specific applications will likely affect
Barnes, et al. Expires August 27, 2013 [Page 5]
Internet-Draft Filtering Considerations February 2013
all applications that depend on those functions.
2.3. Distribution and Mobility
The Internet is designed as a distributed system both geographically
and topologically. Resources can be made globally accessible
regardless of their physical location or connectivity providers used.
Resources are also commonly highly mobile -- moving content from one
physical or logical address to another can often be easily
accomplished.
This distribution and mobility underlies a large part of the
resiliency of the Internet. Internet routing can survive major
outages such as cuts in undersea fibers because the distributed
routing system of the Internet allows individual networks to
collaborate to route traffic and for alternative paths to reach a
given destination to be rapidly computed. Application services are
commonly protected using distributed servers.
Undesirable communications also benefit from this resiliency --
resources that are blocked or restricted in one part of the Internet
can be reconstituted in another part of the Internet (see, for
example, [Malicious-Resolution]). If a web site is prevented from
using a domain name or set of IP addresses, the web site can simply
move to another domain name or network.
The distributed and mobile nature of Internet resources limits the
effectiveness of blocking actions. Because an Internet service can
be reached from anywhere on the Internet, a service that is blocked
in one jurisdiction can often be moved or re-instantiated in another
jurisdiction. Likewise, services that rely on blocked resources can
often be rapidly re-configured to use non-blocked resources. For
example, 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 jursidictions to prevent spam blocking from
being effective. Alternatively, users may choose to use different
sets of protocols to establish desired service. If voice
communication based on SIP [RFC3261] is blocked, users are likely to
use propriety protocols that allow them to talk to each other. Thus
distribution and mobility can hamper efforts to block communications
in a number of ways.
2.4. Locality and Autonomy
The basic unit of Internet routing is an "Autonomous System" -- a
network that manages its own routing internally. The concept of
autonomy is present in many aspects of the Internet, as is the
Barnes, et al. Expires August 27, 2013 [Page 6]
Internet-Draft Filtering Considerations February 2013
related concept of locality, the idea that local changes should not
have a broader impact on the network (where "local" may be denote a
particular service provider or a particular geography).
These concepts are critical to the stability, scalability, and
ability to innovate of the Internet. With millions of individual
actors engineering different parts of the network, there would be
chaos if every change had impact across the entire Internet.
Locality implies that the impact of technical changes made to realize
blocking will only be within a defined scope. For example, changes
to an access network will only affect a relatively small, well-
defined set of users (namely, those connected to the access network),
but can affect all applications for those users. Changes to a
particular application service can affect users across the entire
Internet, but only for that specific application. Thus the scope of
the impact might be narrow in one dimension (set of users or set of
applications affected) but broad in another. In some cases,
applications and/or infrastructure services are so intertwined with
each other that filtering a single service or in a single location
can have broad effects in multiple directions.
Changes made to effectuate blocking are often targeted at a
particular locality, but result in blocking outside of the intended
scope. For example, web filtering systems in India and China have
been shown to cause "collateral damage" by blocking users in Oman and
the US from accessing web sites in Germany and Korea
[IN-OM-filtering][CCS-GFC-collateral-damage].
3. Examples of Blocking
As noted above, systems to restrict or block Internet communications
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, with varying degrees of
effectiveness.
o Firewalls: Firewalls are a very common form of service blocking,
employed at many points in today's Internet. Typically, firewalls
block according to content-neutral rules, e.g., blocking all
inbound connections or outbound connections on certain ports,
protocols and network layer addresses. More advanced
configurations perform deep packet inspection or traffic flow
analysis and filter or block based on rich (content-specific)
rules and policies. Many firewalls include web filtering
capabilities (see below). Firewalls can be deployed either on end
hosts (under user control), or at network boundaries.
Barnes, et al. Expires August 27, 2013 [Page 7]
Internet-Draft Filtering Considerations February 2013
o Web Filtering: HTTP and HTTPS are common targets for blocking and
filtering, typically targeted at specific URLs. 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 URL in an HTTPS request is carried
inside the secure (encrypted) channel. To block access to content
made accessible via HTTPS, filtering systems thus must either
block based only on IP address, 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." These portals present their
own HTTPS certificates that are invalid for any given domain
according to normal validation rules, but may still be trusted if
the user installs a security exception. (See further discussion
in Section 7.)
o Spam Filtering: Spam filtering is one of the oldest forms of
service blocking, in the sense that it denies spammers access to
recipients' mailboxes. Spam filters evaluate messages based on a
variety of criteria and information sources to decide whether a
given message is spam. For example, DNS Reverse Black Lists use
the reverse DNS to flag whether an IP address is a known spam
source [RFC5782]. Spam filters are typically either installed on
user devices (e.g., in a mail client) or operated by a mail domain
on behalf of users.
o Domain name seizure: In recent years, US law enforcement
authorities have been issuing legal orders to domain name
registries to seize domain names associated with the distribution
of counterfeit goods and other allegedly illegal activity
[US-ICE]. When domain names are seized, DNS queries for the
seized names are typically redirected to resolve to U.S.
government IP addresses that host information about the seizure.
The effectiveness of domain seizures is limited by the mobility
principle, since the application using the seized name can simply
use another name. Seizures can come into conflict with the
locality principle, since 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.
o Safe Browsing: Modern web browsers provide some measures to
prevent users from accessing malicious web sites. For instance,
before loading a URL, current versions of Google Chrome and
Barnes, et al. Expires August 27, 2013 [Page 8]
Internet-Draft Filtering Considerations February 2013
Firefox web browsers use the Google Safe Browsing service to
determine whether or not a given URL is safe to load
[SafeBrowsing]. The DNS can also be used to store third party
information that mark domains as safe or unsafe [RFC5782].
o 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.2). These actions have led to
concerns that the number resource certification system and related
secure routing technologies developed by the IETF SIDR working
group might be subject to government manipulation as well
[RFC6480], potentially for the purpose of denying targeted
networks access to the Internet.
4. Blocking Design Patterns
Broadly speaking, completing a typical end-to-end Internet
communication requires the involvement of three classes of entities,
each of which has different means available to it for blocking
communications. An end user originates the communication, which may
be destined for another end user or application provider on the other
end. At these endpoints, authentication and reputation systems
enable devices and their users to make decisions about which
communications should be blocked.
The endpoints are each connected to a series of networks, the
operators of which may also be capable of blocking. Network-based
mechanisms usually involve an intermediary device in the network that
observes Internet traffic and decides which communications to block.
Finally, most communications depend on common "infrastructure"
services (for lack of a better term) that globally support many
different kinds of applications. These include the Domain Name
System, the routing infrastructure, and their supporting information
services such as the WHOIS databases. The operators of these
services can alter the information they store in their associated
databases or provide to endpoints in order to block communications
from occuring.
In this section, we discuss these three "blocking design patterns"
and how they align with the Internet architectural principles
outlined above. In general, endpoint-based blocking is the most
Barnes, et al. Expires August 27, 2013 [Page 9]
Internet-Draft Filtering Considerations February 2013
consistent with the Internet architecture.
4.1. Network-Based Blocking
Being able to block access to resources without the consent or
cooperation of either endpoint to a communication is viewed as a
desirable feature by some entities 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.
Common examples of network-based blocking are firewalls and network-
based web-filtering systems. For example, web filtering devices
usually inspect HTTP requests to determine the URL being requested,
compare that URL to a list of black-listed or white-listed URLs, and
allow the request to proceed only if it is permitted by policy (or at
least not forbidden). 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 filter traffic
based on lower layer criteria (transport protocol and source or
destination addresses or ports).
In addition to blocking communications based on their ultimate
destination or source, network-based blocking may target discovery,
rendezvous or store-and-forward components that are critical to the
establishment of an application service but are not operated at
either end-point of the communications. For example, to establish an
end-to-end SIP call the end-nodes (terminals) will rely on presence
and session information supplied by SIP servers. Network operators
can block the use of SIP-based services by blocking access to SIP
servers. [Q: Does this actually happen?]
It should be noted that "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 users. 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.3 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
Barnes, et al. Expires August 27, 2013 [Page 10]
Internet-Draft Filtering Considerations February 2013
architectural perspective, however, they may create many of the same
problems as network-based filtering conducted without consent.
4.1.1. Interaction with Architectural Principles
Blocking that uses intermediaries in the network conflicts with the
end-to-end and transparency principles noted above. The very goal of
blocking in this way is to impede transparency for particular content
or communications. For this reason, intermediary-based approaches to
blocking run into several technical issues that limit their viability
in practice. In particular, many issues arise from the fact that an
intermediary needs to have access to a sufficient amount of traffic
to make its blocking determinations.
The first challenge to obtaining this traffic is simply gaining
access to the constituent packets. The Internet is designed to
deliver packets hop-by-hop from source to destination -- not to any
particular point along the way. In practice, inter-network routing
is often asymmetric, and for sufficiently complex local networks,
intra-network traffic flows can be asymmetric as well.
This asymmetry means that an intermediary will often see only one
half of a given communication (if it sees any of it at all), which
may limit its ability to effectively filter. For example, a filter
aimed at requests destined for particular URLs cannot make accurate
blocking decisions if it is only in the data path for HTTP responses
and not requests. 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 often reduce network performance relative
to asymmetric routing.
Once an intermediary 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 (URLs or other
content). 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 (in violation of
the locality principle.)
4.1.2. Circumvention
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
Barnes, et al. Expires August 27, 2013 [Page 11]
Internet-Draft Filtering Considerations February 2013<displayreference target="RFC6449" to="RFC-dev"/>
If a reference section is sorted, this element changes the sort
order.
This element appears as a child element of: <back> (Section 2.8).
Content model: this element does not have any contents.
2.19.1. 'target' attribute (mandatory)
This attribute must be the name of an anchor in a <reference>
element.
2.19.2. 'to' attribute (mandatory)
This attribute is a name that will be displayed as the anchor instead
of the anchor that is given in the <reference> element. The string
given must start with one of the following characters: 0-9, a-z, A-Z.
The other characters in the string must be 0-9, a-z, A-Z, "-", ".",
and "_".
2.20. <dl>
A definition list. Each entry has a pair of elements: a term (<dt>)
and a definition (<dd>). (This is slightly different than the model
used in HTML, whicl allows for multiple terms for a single
definition.)
This element appears as a child element of: <abstract> (Section 2.1),
<aside> (Section 2.6), <blockquote> (Section 2.10), <dd>
(Section 2.18), <li> (Section 2.29), <note> (Section 2.33), <section>
(Section 2.46), <td> (Section 2.56), and <th> (Section 2.58).
Content model:
One or more sequences of:
1. One <dt> element
2. One <dd> element
2.20.1. 'anchor' attribute
Document-wide unique identifier for the list.
Hoffman Expires December 19, 2015 [Page 26]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.20.2. 'hanging' attribute
The hanging attribute defines whether or not the term appears on the
same line as the definition. hanging="true" indicates that the term
is to the left of the definition, while hanging="false" indicates
that the term will be on a separate line.
Allowed values:
o "false"
o "true" (default)
2.20.3. 'spacing' attribute
Defines whether or not there is a blank line between entries.
spacing="normal" indicates a single blank line, while
spacing="compact" indicates no space between.
Allowed values:
o "normal" (default)
o "compact"
2.21. <dt>
The term being defined in a definition list.
This element appears as a child element of: <dl> (Section 2.20).
Content model:
In any order:
o Text
o <bcp14> elements (Section 2.9)
o <cref> elements (Section 2.16)
o <em> elements (Section 2.22)
o <eref> elements (Section 2.24)
o <iref> elements (Section 2.27)
Hoffman Expires December 19, 2015 [Page 27]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
o <relref> elements (Section 2.44)
o <strong> elements (Section 2.50)
o <sub> elements (Section 2.51)
o <sup> elements (Section 2.52)
o <tt> elements (Section 2.62)
o <xref> elements (Section 2.66)
2.21.1. 'anchor' attribute
Document-wide unique identifier for this term.
2.22. <em>
Indicates text that is semantically empahsized. This element will be
displayed as italic after processing. This element can be combined
with other character formatting elements, and the formatting will be
additive.
This element appears as a child element of: <annotation>
(Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16),
<dd> (Section 2.18), <dt> (Section 2.21), <li> (Section 2.29),
<preamble> (Section 3.6), <refcontent> (Section 2.39), <strong>
(Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), <t>
(Section 2.53), <td> (Section 2.56), <th> (Section 2.58), and <tt>
(Section 2.62).
Content model:
In any order:
o Text
o <bcp14> elements (Section 2.9)
o <cref> elements (Section 2.16)
o <eref> elements (Section 2.24)
o <iref> elements (Section 2.27)
o <relref> elements (Section 2.44)
Hoffman Expires December 19, 2015 [Page 28]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
o <strong> elements (Section 2.50)
o <sub> elements (Section 2.51)
o <sup> elements (Section 2.52)
o <tt> elements (Section 2.62)
o <xref> elements (Section 2.66)
2.23. <email>
Provides an email address.
The value is expected to be the scheme-specific part of a "mailto"
URI (so does not include the prefix "mailto:"). See Section 2 of
[RFC6068] for details.
This element appears as a child element of: <address> (Section 2.2).
Content model: only text content.
2.23.1. 'ascii' attribute
The ASCII equivalent of the author's email address. This is only
used if the email address has one or two internationalized
components.
2.24. <eref>
Represents an "external" link (as specified in the "target"
attribute). This is useful for embedding URIs in the body of a
document.
If the <eref> element has non-empty text content, formatters should
use the content as the displayed text that is linked. Otherwise the
formatter should use the value of the "target" attribute as the
displayed text. Formatters will link the displayed text to the value
of the "target" attribute in a manner appropriate for the output
format.
For example, with an input of:
This is described at
<eref target="http://www.example.com/reports/r12.html"/>.
An HTML formatter might generate
Hoffman Expires December 19, 2015 [Page 29]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
This is described at
<a href="http://www.example.com/reports/r12.html">
http://www.example.com/reports/r12.html</a>.
With an input of:
This is described
<eref target="http://www.example.com/reports/r12.html">
in this interesting report</eref>.
An HTML formatter might generate
This is described
<a href="http://www.example.com/reports/r12.html">
in this interesting report</a>.
This element appears as a child element of: <annotation>
(Section 2.3), <blockquote> (Section 2.10), <c> (Section 3.1), <cref>
(Section 2.16), <dd> (Section 2.18), <dt> (Section 2.21), <em>
(Section 2.22), <li> (Section 2.29), <name> (Section 2.32),
<postamble> (Section 3.5), <preamble> (Section 3.6), <strong>
(Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), <t>
(Section 2.53), <td> (Section 2.56), <th> (Section 2.58), <tt>
(Section 2.62), and <ttcol> (Section 3.9).
Content model: only text content.
2.24.1. 'target' attribute (mandatory)
URI of the link target (see Section 3 of [RFC3986]). This must begin
with a scheme name (such as "https://") and thus not be relative to
the URL of the current document.
2.25. <figure>
Contains a figure with a caption with the figure number. If the
element contains a <name> element, the caption will also show that
name.
This element appears as a child element of: <aside> (Section 2.6),
<blockquote> (Section 2.10), <dd> (Section 2.18), <li>
(Section 2.29), <section> (Section 2.46), <td> (Section 2.56), and
<th> (Section 2.58).
Content model:
In this order:
Hoffman Expires December 19, 2015 [Page 30]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
1. One optional <name> element (Section 2.32)
2. Optional <iref> elements (Section 2.27)
3. One optional <preamble> element (Section 3.6)
4. In any order, but at least one of:
* <artwork> elements (Section 2.5)
* <sourcecode> elements (Section 2.48)
5. One optional <postamble> element (Section 3.5)
2.25.1. 'align' attribute
Deprecated.
Note: does not affect title or <artwork> alignment.
Allowed values:
o "left" (default)
o "center"
o "right"
2.25.2. 'alt' attribute
Deprecated. If the goal is to provide a single URI for a reference,
use the "target" attribute on <reference> instead.
2.25.3. 'anchor' attribute
Document-wide unique identifier for this figure.
2.25.4. 'height' attribute
Deprecated.
2.25.5. 'src' attribute
Deprecated.
Hoffman Expires December 19, 2015 [Page 31]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.25.6. 'suppress-title' attribute
Deprecated. Figures always now get captions.
Allowed values:
o "true"
o "false" (default)
2.25.7. 'title' attribute
Deprecated. Use <name> instead.
2.25.8. 'width' attribute
Deprecated.
2.26. <front>
Represent the "front matter": metadata (such as author information),
abstract, and additional notes.
A <front> element may have more than one <seriesInfo> elements. A
<seriesInfo> element determines the document number (for RFCs) or
name (for Internet-Drafts). Another <seriesInfo> element determines
the "maturity level" (see Section 4 of [RFC2026]), using values of
"std" for "Standards Track", "bcp" for "BCP", "info" for
"Informational", "exp" for "Experimental", and "historic" for
"Historic". The "name" attributes of those multiple <seriesInfo>
elements interact as described in the section on <seriesInfo>.
This element appears as a child element of: <reference>
(Section 2.40), and <rfc> (Section 2.45).
Content model:
In this order:
1. One <title> element (Section 2.60)
2. One or more <author> elements (Section 2.7)
3. One optional <date> element (Section 2.17)
4. Optional <area> elements (Section 2.4)
Hoffman Expires December 19, 2015 [Page 32]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
5. Optional <workgroup> elements (Section 2.65)
6. Optional <keyword> elements (Section 2.28)
7. One optional <abstract> element (Section 2.1)
8. Optional <seriesInfo> elements (Section 2.47)
9. Optional <note> elements (Section 2.33)
10. One optional <boilerplate> element (Section 2.11)
2.27. <iref>
Provides terms for the document's index.
Index entries can be either be regular entries (when just the "item"
attribute is given) or nested entries (by specifying "subitem" as
well), grouped under a regular entry.
Index entries generally refer to the exact place where the <iref>
element occured. An exception is the occurence as a child element of
<section>, in which case the whole section is considered to be
relevant for that index entry. In some formats, index entries of
this type might be displayed as range.
When the prep tool is creating index content, it collects the items
in a case-senstive fashion for both the item and subitem level.
This element appears as a child element of: <annotation>
(Section 2.3), <aside> (Section 2.6), <blockquote> (Section 2.10),
<c> (Section 3.1), <dd> (Section 2.18), <dt> (Section 2.21), <em>
(Section 2.22), <figure> (Section 2.25), <li> (Section 2.29),
<postamble> (Section 3.5), <preamble> (Section 3.6), <section>
(Section 2.46), <strong> (Section 2.50), <sub> (Section 2.51), <sup>
(Section 2.52), <t> (Section 2.53), <table> (Section 2.54), <td>
(Section 2.56), <th> (Section 2.58), <tt> (Section 2.62), and <ttcol>
(Section 3.9).
Content model: this element does not have any contents.
2.27.1. 'item' attribute (mandatory)
The item to include.
Hoffman Expires December 19, 2015 [Page 33]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.27.2. 'primary' attribute
Setting this to "true" declares the occurrence as "primary", which
might cause it to be highlighted in the index.
Allowed values:
o "true"
o "false" (default)
2.27.3. 'subitem' attribute
The subitem to include.
2.28. <keyword>
Specifies a keyword applicable to the document.
Note that each element should only contain a single keyword; for
multiple keywords, the element can simply be repeated.
Keywords are used both in the RFC Index and in the metadata of
generated document representations.
This element appears as a child element of: <front> (Section 2.26).
Content model: only text content.
2.29. <li>
A list element, used in <ol> and <ul>.
This element appears as a child element of: <ol> (Section 2.34), and
<ul> (Section 2.63).
Content model:
Either:
In any order, but at least one of:
* <artwork> elements (Section 2.5)
* <dl> elements (Section 2.20)
Hoffman Expires December 19, 2015 [Page 34]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
* <figure> elements (Section 2.25)
* <ol> elements (Section 2.34)
* <sourcecode> elements (Section 2.48)
* <t> elements (Section 2.53)
* <ul> elements (Section 2.63)
Or:
In any order, but at least one of:
* Text
* <bcp14> elements (Section 2.9)
* <cref> elements (Section 2.16)
* <em> elements (Section 2.22)
* <eref> elements (Section 2.24)
* <iref> elements (Section 2.27)
* <relref> elements (Section 2.44)
* <strong> elements (Section 2.50)
* <sub> elements (Section 2.51)
* <sup> elements (Section 2.52)
* <tt> elements (Section 2.62)
* <xref> elements (Section 2.66)
2.29.1. 'anchor' attribute
Document-wide unique identifier for this list item.
Hoffman Expires December 19, 2015 [Page 35]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
2.30. <link>
A link to an external document that is related to the RFC.
The following are the supported types of external documents that can
be pointed to in a <link> element:
o The current ISSN for the RFC Series. The value for the "rel"
attribute is "item". The link should use the form "urn:issn:".
o The DOI for this document. The value for the "rel" attribute is
"describedBy". The link should use the form specified in [DOI].
o The Internet Draft that was submitted to the RFC Editor to become
the published RFC. The value for the "rel" attribute is
"derivedFrom". The link should be to an IETF-controlled web site
that retains copies of Internet Drafts.
o A representation of the document offered by the document author.
The value for the "rel" attribute is "alternate". The link can be
to a personally-run web site.
In RFC production mode, the prep tool needs to check the values for
<link> before an RFC is published. In draft production mode, the
prep tool might remove some <link> elements during the draft
submission process.
This element appears as a child element of: <rfc> (Section 2.45).
Content model: this element does not have any contents.
2.30.1. 'href' attribute (mandatory)
The URI of the external document.
2.30.2. 'rel' attribute
The relationship of the external document to this one. The
relationships are taken from Link Relations registry maintained by
IANA [LINKRELATIONS].
2.31. <middle>
Represents the main content of the document.
This element appears as a child element of: <rfc> (Section 2.45).
Content model:
Hoffman Expires December 19, 2015 [Page 36]
Internet-Draft The 'XML2RFC' version 3 Vocabulary June 2015
One or more <section> elements (Section 2.46)
2.32. <name>
The name of the section, note, figure, or texttable. This name can
have flow markup such as to make some characters use a fixed-width
font, or to include references.
This element appears as a child element of: <figure> (Section 2.25),
<note> (Section 2.33), <references> (Section 2.42), <section>
(Section 2.46), <table> (Section 2.54), and <texttable>
(Section 3.8).
Content model:
In any order:
o Text
o <cref> elements (Section 2.16)
o <eref> elements (Section 2.24)
o <relref> elements (Section 2.44)
o <tt> elements (Section 2.62)
o <xref> elements (Section 2.66)
2.33. <note&
(see below). IP addresses must be visible, even if packets are
protected with IPsec, but blocking based on IP addresses is the
simplest form of filtering 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. Indeed, in the
face of IP-based blocking in some networks, services such as The
Pirate Bay are now using cloud hosting services so that their IP
addresses are difficult for intermediaries to predict
[BT-TPB][TPB-cloud].
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. Since security
protocols are 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) enable users to detect these sort
of intermediaries. Those users are then likely to act as if the
service is blocked.
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 and port
numbers. 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.
However, as the Telex project 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 [Telex]. For example, if an ISP used by a banking website
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).
Thus, in principle it is impossible to block tunneled traffic through
an intermediary device without blocking all secure traffic. (The
only limitation in practice is the requirement for special software
on the client.) In most cases, blocking all secure traffic is an
unacceptable consequence of blocking, since security is often
required for services such as online commerce, enterprise VPNs, and
management of critical infrastructure. If governments or network
operators were to force these services to use insecure protocols so
Barnes, et al. Expires August 27, 2013 [Page 12]
Internet-Draft Filtering Considerations February 2013
as to effectuate blocking, they would 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 intermediary-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.
Network-based blocking is a key contributor to the arms race that has
led to the development of these kinds of 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 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. 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.
In sum, blocking via intermediaries within networks 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), which may be
resource-prohibitive, especially if tunnel endpoints begin to change
frequently. 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.
Barnes, et al. Expires August 27, 2013 [Page 13]
Internet-Draft Filtering Considerations February 2013
4.2. Infrastructure-Based Blocking
Internet applications often require or rely on support from common,
global infrastructure services, including the DNS, certificate
authorities, 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.
These infrastructure 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; the RPKI about which entities have been
allocated IP addresses. To offer specialized Internet services and
applications, different entities 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).
As physical objects, the servers that are used to provide
infrastructure services exist within the jurisdiction of governments,
and their operators are thus subject to jurisdictional laws. It is
thus possible for laws to be structured to effectuate blocking by
imposing obligations on the operators of infrastructure services
within a jurisdiction, either via direct government action or by
allowing private actors to demand blocking (e.g., through lawsuits).
Blocking by infrastructure operators is at odds with the locality
principle. On the one hand, the global nature of Internet services
and resources amplifies blocking actions, in the sense that it
increases the risk of overblocking -- collateral damage to legitimate
use of a resource. A given address or domain name might host both
legitimate services and services that governments desire to block. A
service hosted under a domain name and operated in a jurisdiction
where it is considered undesirable might be considered legitimate in
another jurisdiction; a blocking action in the host jurisdiction
would deny legitimate services in the other.
The efficacy of infrastructure-based blocking is further limited by
the autonomy principle. 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 the infrastructure
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.
Barnes, et al. Expires August 27, 2013 [Page 14]
Internet-Draft Filtering Considerations February 2013
Below we provide a few specific examples for routing, DNS, and WHOIS
services. These examples demonstrate that for these types of
infrastructure services (services that are often considered a global
commons), jusrisdiction-specific legal and ethical motivations
impinge on and are constrained by the principles of locality and
autonomy.
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 route leak beyond the Pakistan
ISP's scope (violation of locality), but service was restored in
approximately two hours because network operators around the world
re-configured their routers to ignore the bogus routes [RenesysPK]
(which demonstrates autonomy). In the context of SIDR and secure
routing, a similar re-configuration could theoretically be done if a
resource certificate were to be revoked in order to block routing to
a given network.
In the DNS realm, one of the recent cases of US law enforcement
seizing domain names involved RojaDirecta, a Spanish web site. Even
though several of the affected domain names belonged to Spanish
entities, they were subject to blocking by the US government because
certain servers were operated in the US. 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
US-government-operated name servers. Users of other services under a
target name (e.g. e-mail) would thus be unable to locate the servers
providing services for that name, denying them the ability to access
these services (violation of locality).
Similar work-arounds 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
un-blocked results for the affected name. However, depending on
availability of valid signature data, these types of workarounds will
not work with DNSSEC signed data.
The action of the Dutch authorities against the RIPE NCC, where RIPE
was ordered to freeze the accounts 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
Barnes, et al. Expires August 27, 2013 [Page 15]
Internet-Draft Filtering Considerations February 2013
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, violating locality, and in that reduced trust
in the global system may encourage networks to develop their own
autonomous solutions.
Blocking of infrastructure 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 balkanisation, 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 ISOC's whitepaper on DNS
filtering [ISOCFiltering], but they also apply to other global
Internet resources.
In summary, infrastructure-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 often have harmful
side effects due to the global nature of Internet resources. 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
infrastructure-based blocking can be negated on short order in some
cases. To adapt a quote by John Gilmore, "The Internet treats
blocking as damage and routes around it".
4.3. Endpoint-Based Blocking
[TO DO: Should this section only address "user"-based blocking or
should it also discuss server-based blocking (e.g., a web server that
prevents abusive users from accessing content?)]
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
Barnes, et al. Expires August 27, 2013 [Page 16]
Internet-Draft Filtering Considerations February 2013
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
blocking systems in the Internet; modern blocking 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 blocking systems (browsers, MTAs) share a single reputation
service.
This approach to blocking is consistent with the Internet
architectural principles discussed above, dealing well with the end-
to-end principle, layering, mobility, and locality/autonomy.
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 intermediary-based blocking runs into.
Endpoint-based blocking also lacks some of the limitations of
infrastructure-based blocking: while infrastructure-based blocking
can only see and affect the infrastructure service at hand (e.g., DNS
name resolution), endpoint-based blocking (depending on how it is
designed) can have visibility into the entire application, across all
layers and transactions. This visibility can provide endpoint-based
blocking systems with a much richer set of information on which to
make blocking decisions.
In particular, endpoint-based blocking deals well with adversary
mobility. If a blocked service relocates resources or uses different
resources, an infrastructure- 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.
Finally, 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.
The primary challenge to endpoint-based blocking is that it requires
Barnes, et al. Expires August 27, 2013 [Page 17]
Internet-Draft Filtering Considerations February 2013
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.
5. Summary of Trade-offs
Network-based blocking is a relatively low-cost blocking solution in
some cases, but a poor fit with the Internet architecture, especially
the end-to-end principle. It thus suffers from several limitations.
o Examples: Firewalls, web filtering systems.
o A single intermediary device can be used to block the access of
many users to many services.
o Network-based blocking can be done without the cooperation of
either endpoint to a communication (although having that
cooperation makes it more likely to be effective).
o Network intermediaries often lack sufficient information to make
blocking decisions, due to routing asymmetry or encryption.
o Network-based blocking sometimes involves breaking end-to-end
security assurances.
o Tunneling through blocking is difficult to prevent without
preventing legitimate secure services.
Infrastructure-based blocking can provide rapid effects for resources
under the control of the blocking entity, but its ultimate
effectiveness is limited by the global, autonomous nature of Internet
resources and networks, and it may create undesirable collateral
damage to Internet services.
o Examples: Domain name seizures, WHOIS account freezing, RPKI
certificate revocation.
o Internet services that depend on specific resources can be blocked
by disabling those resources.
Barnes, et al. Expires August 27, 2013 [Page 18]
Internet-Draft Filtering Considerations February 2013
o Blocked resources can often be easily relocated or reinstantiated
in a location where they will not be blocked.
o Resources used by undesirable services are often also used by
legitimate services, resulting in collateral damage.
o Autonomy of Internet networks and users allows them to "route
around" blocking. [OK Perhaps: Autonomy principle allows users to
innovatively find methods to route around the blocking.]
Endpoint-based blocking matches well with the overall design of the
Internet.
o Examples: Safe browsing, spam filtering
o Endpoints block services by deciding whether or not to engage in a
given communication.
o Blocking system has full visibility into all layers involved in a
communication.
o Adversary mobility can be quickly observed so that blocking
systems can be updated to account for it.
o Requires cooperation of endpoints.
6. Conclusion
Because it agrees so well with Internet architectural principles,
endpoint-based blocking is the form of Internet service blocking that
is least harmful to the Internet. From a technical perspective, it
is the most preferred option because it maintains transparency of the
network, vests functionality at the endpoints in accordance with the
end-to-end principle, can be applied granularly so as to avoid
collateral damage, and accommodates mobile adversaries. Entities
seeking to filter and for whom endpoint-based blocking is a potential
choice should view its technical benefits as distinct advtanges
compared to the other approaches.
In reality, the various approaches discussed above are all applied
for different reasons, and particular entities may not consider
endpoint-based filtering to be viable. Often, the choice of a
filtering solution is constrained by practical limitations on which
parts of the network are under the control of the entity implementing
filtering, and which parts of the network are trusted to cooperate.
For example, an ISP that is subject to filtering requirements might
implement an intermediary-based filtering approach because it cannot
Barnes, et al. Expires August 27, 2013 [Page 19]
Internet-Draft Filtering Considerations February 2013
be sure that endpoints will cooperate in filtering. As discussed
above, government agencies tasked with disabling certain foreign web
sites have done so by manipulating infrastructure servers that are
within their own jurisdictions, based on legal claims to obtain
access to those servers. An enterprise with filtering requirements
might require employees to install a certain filtering software
package on enterprise-owned PCs.
It is therefore realistic to expect that certain entities will
continue to attempt to conduct network- or infrastructure-based
filtering since they may not have control over the endpoints they
wish to affect or because the endpoints do not have incentives to
consent to the filtering. In some cases, an approach that combines
one of these with endpoint-based filtering can help strike a better
balance. For example, a filtering system might make it possible for
some endpoints to cooperate or "opt in" to filtering, rather than
deploying a purely network-based solution.
While this document has focused on technical mechanisms used to
filter Internet content, a variety of non-technical mechanisms may
also be available depending on the particular context and goals of
the public or private entity seeking to restrict access to content.
For example, purveyors of illegal online content can be pursued
through international cooperation, by using the criminal justice
system, and by targeting the funding that supports their activities
through collaboration with financial services companies
[click-trajectories]. Thus even in cases where endpoint-based
filtering is not viewed as a viable means of restricting access to
content, entities seeking to filter may find other strategies for
achieving their goals that do not involve interfering with the
architecture or operation of the Internet.
Those with a desire to filter should take into account the
limitations discussed in this document and holistically assess the
space of technical and non-technical solutions at their disposal and
the likely effectiveness of each combination of approaches.
7. Security Considerations
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
typically require the blocking system to defeat the authentication
mechanisms built into security protocols.
Barnes, et al. Expires August 27, 2013 [Page 20]
Internet-Draft Filtering Considerations February 2013
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 website, 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.
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, he
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 vulnarable.
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.
Security protocols can, of course, also be used a mechanism 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.
8. Informative References
[BT-TPB] Meyer, D., "BT blocks The Pirate Bay", June 2012, <http://
www.zdnet.com/bt-blocks-the-pirate-bay-4010026434/>.
[CCS-GFC-collateral-damage]
"The Collateral Damage of Internet Censorship by DNS
Injection", July 2012, <http://conferences.sigcomm.org/
sigcomm/2012/paper/ccr-paper266.pdf>.
[EarthquakeHT]
Raj Upadhaya, G., ".ht: Recovering DNS from the Quake",
March 2010, <http://www.apricot.net/apricot2010/__data/
Barnes, et al. Expires August 27, 2013 [Page 21]
Internet-Draft Filtering Considerations February 2013
assets/pdf_file/0019/19018/
Lightning-Talk_03_Gaurab-Upadhaya-dotht-apricot-
lightning.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>.
[IN-OM-filtering]
Citizen Lab, "Routing Gone Wild", July 2012,
<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>.
[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>.
[Morris] Kehoe, B., "The Robert Morris Internet Worm", 1992, <http:
//groups.csail.mit.edu/mac/classes/6.805/articles/
morris-worm.html>.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle
and the Future of End-to-End: Reflections on the Evolution
of the Internet Architecture", RFC 3724, March 2004.
Barnes, et al. Expires August 27, 2013 [Page 22]
Internet-Draft Filtering Considerations February 2013
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4084] Klensin, J., "Terminology for Describing Internet
Connectivity", BCP 104, RFC 4084, May 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet
Transparency", RFC 4924, July 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
February 2010.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RenesysPK]
Brown, M., "Pakistan hijacks YouTube", February 2008, <htt
p://www.renesys.com/blog/2008/02/
pakistan_hijacks_youtube_1.shtml>.
[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>.
[SAC-056] "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>.
[SafeBrowsing]
Google, "Safe Browsing API", 2012,
<https://developers.google.com/safe-browsing/>.
[TPB-cloud]
"The Pirate Cloud", October 2012,
<http://thepiratebay.se/blog/224>.
[Telex] Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman,
"Telex: Anticensorship in the Network Infrastructure",
Barnes, et al. Expires August 27, 2013 [Page 23]
Internet-Draft Filtering Considerations February 2013
August 2011, <https://telex.cc/>.
[Tor] "Tor Project: Anonymity Online", 2012,
<https://www.torproject.org/>.
[US-ICE] U.S. Immigration and Customs Enforcement, "Operation in
Our Sites", 2011, <http://www.ice.gov/doclib/news/library/
factsheets/pdf/operation-in-our-sites.pdf>.
[click-trajectories]
Levchenko, K., Pitsillidis, A., Chacra, N., Enright, B.,
Felegyhazi, M., Grier, C., Halvorson, T., Kreibich, C.,
Liu, H., McCoy, D., Weaver, N., Paxson, V., Voelker, G.,
and S. Savage, "Click Trajectories: End-to-End Analysis of
the Spam Value Chain", 2011,
<http://cseweb.ucsd.edu/~savage/papers/Oakland11.pdf>.
Authors' Addresses
Richard Barnes
BBN Technologies
1300 N. 17th St
Arlington, VA 22209
USA
Phone: +1 703 284 1340
Email: rbarnes@bbn.com
Alissa Cooper
CDT
1634 Eye St. NW, Suite 1100
Washington, DC 20006
USA
Email: acooper@cdt.org
Olaf Kolkman
NLnet Labs
Science Park 400
Amsterdam 1422 JB
Netherlands
Email: olaf@nlnetlabs.nl
Barnes, et al. Expires August 27, 2013 [Page 24]