+------+--------------+ | | +--------+-------------+
| +------+------+ |
| +-------------+ | |
V V V V
+-----------------+ +------------------+
| Virtuous Data | | Salacious Data |
+-----------------+ +------------------+
4.1.4. Particular Protocol Difficulties
There are additional considerations related to particular protocols.
We consider only a few here. The first two, electronic mail and the
World Wide Web, use domain name addressing. The second two, net news
and IRC, use different name spaces and illustrate further technical
problems with name based labeling.
4.1.4.1. Electronic Mail (SMTP)
Standard Internet tools provide no way to stop users from putting
arbitrary domain names inside email headers.
The standard Internet electronic mail protocol separates "envelope"
information from content [RFC 2821, 2822]. The envelope information
indicates where a message claims to have originated and to whom it
should be delivered. The content has fields starting with labels
like "From:" and "To:", but these content fields actually have no
effect and can be arbitrarily forged using simple, normally available
software, such a telnetting to the SMTP port on a mail server.
Content fields are not compared with envelope fields. To require
them to be the same would be like requiring that postal letters
deposited in a mail box list that mail box as their return address
and only allowing residence or business return addresses on mail
picked up by the post office from that residence or business.
While different mail clients display envelope information and headers
from the content of email differently, generally the principle
content fields are given prominence. Thus, while not exactly the
same as content labeling, it should be noted that it is trivial to
send mail to anyone with arbitrary domain names in the email
addresses appearing in the From and To headers, etc.
It is also easy up set up a host to forward mail to an email address
or mailing list. Mail sent with normal mail tools to this forwarder
will automatically have content headers reflecting the forwarder’s
name, but the forwarder will change the envelope information and
cause the mail to be actually sent to the forwarding destination mail
address.
For example, (with names disguised) there is a social mailing list
innocuous@foo.example.org, and someone set up a forwarder at
cat-torturers@other.example. Mail sent to the forwarder is forwarded
and appears on the innocuous mailing list but with a "To: cat-
torturers@other.example" header in its body, instead of the usual
"To: innocuous@foo.example.org" content header. Mail reader software
then displays the cat-torturers header. Similar things can be done
using the "bcc" or "blind courtesy copy" feature of Internet mail.
There is work proceeding on securing email; however, such efforts at
present only allow you to verify whether or not a particular entity
was the actual author of the mail. When providing authentication,
they add yet a third type of "From" address to the envelope and
content "From" addresses, but they do not relate to controlling or
authenticating domain names in the content of the mail.
4.1.4.2. Web Access (HTTP)
With modern web servers and browsers supporting HTTP 1.1 [RFC 2616],
the domain name used to access the site is available. Thus, web
sites with different domain names can be accessed even if they are on
the same machine at the same IP address. This is a small plus for
name-based labeling since different categories of information on the
same computer can be set up to be accessed via different domain
names. But for a computer with any reasonable variety of data, the
explosion of trying to differently name all types of data would
require an unmanageable number of names.
With earlier HTTP 1.0 [RFC 1945], when a web request was sent to a
server machine, the original domain name used in the URI was not
included.
On the other hand, the web has automatic forwarding. Thus, when one
tries to access data at a particular domain name, the server there
can re-direct your browser, temporarily or permanently, to a
different name, or it can re-direct you to a numeric IP address so as
to by-pass name filtering.
4.1.4.3. News (NNTP)
Net news [RFC 977, 2980] uses hierarchically structured newsgroup
names that are similar in appearance to domain names, except that the
most significant label is on the left and the least on the right, the
opposite of domain names. However, while the names are structured
hierarchically, there is no central control. Instead, news servers
periodically connect to other news servers that have agreed to
exchange messages with them and they update each other on messages
only in those newsgroups in which they wish to exchange messages.
Although hierarchical zones in the domain name system are locally
managed, they need to be reachable starting at the top level root
servers which are in turn more or less controlled by ICANN and the US
Department of Commerce. With no such central point or points in the
net news world, any pair or larger set of news servers anywhere in
the world can agree to exchange news messages under any news group
names they like, including duplicates of those used elsewhere in the
net, making central control or even influence virtually impossible.
In fact, within some parts of the news group namespace on some
servers, anyone can create new newsgroups with arbitrary names.
Even if news group names could be controlled, the contents of the
messages are determined by posters. While some groups are moderated,
most are not. "Cancel" messages can be sent out for news messages,
but that mechanism is subject to abuse, so some servers are
configured to ignore cancels. In any case, the message may have been
distributed to a huge number of computers world wide before any
cancel is sent out.
And of course, fitting 300 bits worth of labeling into news group
names is just as impossible as it is to fit into domain names.
4.1.4.4. Internet Relay Chat (IRC)
Internet Relay Chat [RFC 2810-2813] is another example of a service
which uses a different name space. It uses a single level space of
"channel names" that are meaningful within a particular network of
IRC servers. Because it is not hierarchical, each server must know
about all names, which limits the size of a network of servers.
As with newsgroup names, the fact that IRC channel names are local
decisions, not subject to or reachable from any global "root", makes
centralized political control virtually impossible.
4.2. Content Filtering Using IP Addressing
A key characteristic of the Internet Protocol (IP) on which the
Internet is based is that it breaks data up into "packets". These
packets are individually handled and routed from source to
destination. Each packet carries a numeric address for the
destination point to which the Internet will try to deliver the
packet.
(End users do not normally see these numeric addresses but instead
deal with "domain names" as described in section 4.1. above.)
The predominant numeric address system now in use is called IPv4, or
Internet Protocol Version 4, which provides for 32 bit addresses [RFC
791]. There is increasing migration to the newer IPv6 [RFC 2460],
which provides for 128 bit addresses [RFC 2373, 2374].
Packets can be modified maliciously in transit but the most common
result of this is denial of service.
One problem in using addressing for content filtering is that this is
a very coarse technique. IP addresses refer to network interfaces,
which usually correspond to entire computer systems which could house
multiple web pages, sets of files, etc., only a small part of which
it was desired to block or enable. Increasingly, a single IP address
may correspond to a NAT (Network Address Translation) box [RFC 2663]
which hides multiple computers behind it, although in that case,
these computers are usually not servers.
However, even beyond this problem of coarse granularity, the
practical constraints of hierarchical routing make the allocation of
even a single IPv4 address bit or a significant number of IPv6
address bits impossible.
4.2.1. Hierarchical Routing
IP addresses are technically inappropriate for content filtering
because their assignment is intimately tied to network routing and
topology.
As packets of data flow through the Internet, decisions must be made
as to how to forward them "towards" their destination. This is done
by comparing the initial bits of the packet destination address to
entries in a "routing table" and forwarding the packets as indicated
by the table entry with the longest prefix match.
While the Internet is actually a mesh, if, for simplicity, we
consider it to have a central backbone at the "top", a packet is
typically routed as follows:
The local networking code looks at its routing table to determine if
the packet should be sent directly to another computer on the "local"
network, to a router to specially forward it to another nearby
network, or routed "up" to a "default" router to forward it to a
higher level service provider’s network. If the packet’s destination
is "far enough away", it will eventually get forwarded up to a router
on the backbone. Such a router cannot send the packet "up" since it
is at the top, or "default free" zone, and must have a complete table
of other top level routers in which to send the packet. Currently,
such top level routers are very large and expensive devices. They
must be able to maintain tables of tens of thousands of routes. When
the packet gets to the top level router of the part of the network
within which its destination lies, it gets forwarded "down" to
successive routers which are more and more specific and local until
eventually it gets to a router on the local network where its
destination address lies. This local router sends the packet
directly to the destination computer.
Because all of these routing decisions are made on a longest prefix
match basis, it can be seen that IP addresses are not general names
or labels, but are critically and intimately associated with the
actual topology and routing structure of the network. If they were
assigned at random, routers would be required to remember so many
specific routes for specific addresses that it would far exceed the
current technical capabilities for router design. The Internet would
be fatally disrupted and would not work.
It should also be noted that there is some inefficiency in allocation
at each level of hierarchy [RFC 1715]. Generally, allocations are of
a power of two addresses and as requirements grow and/or shrink, it
is not practical to use every address.
(The above simplified description ignores multi-homing and many other
details.)
4.2.2. IP Version 4 Addresses
There just isn’t any practical way to reallocate even one bit of IPv4
global Internet Addresses for content filtering use. Such addresses
are in short supply. Such an allocation would, in effect, cut the
number of available addresses in half. There just aren’t enough
addresses, even without the inefficiency of hierarchical allocation
[RFC 1715] and routing, to do this. Even if there were, current
numbers have not been allocated with this in mind so that renumbering
by every organization with hosts on the Internet would be required, a
Herculean task costing in the billions of dollars.
Even if these problems were overcome, the allocation of even a single
bit near the top of the address bits would likely double the number
of routes in the default free zone. This would exceed the capacity
of current routers and require the upgrade of thousands of them to
new routers that do not exist yet at a gargantuan cost. The
allocation of a bit near the bottom of the address bits would require
world-wide local reconfiguration which would be impractical to
require or enforce, even if the bit were available.
And all this is if only a single bit is allocated to content
labeling, let alone more than one. And we are assuming you would
actually need 300 bits, more than there are!
Basically, the idea is a non-starter.
4.2.3. IP Version 6 Addresses
IPv6 provides 128 bit address fields [RFC 2373, 2374]. Furthermore,
allocation of IPv6 addresses is in its infancy. Thus, the allocation
of say, one bit of IPv6 address for labeling is conceivable.
However, as discussed above (section 4.2.1.), every high bit
allocated for labeling doubles the cost imposed on the routing
system. Allocating one bit would generally double the size of
routing tables.
Allocating two bits would multiply them by four. Allocating the 300
bits we assume necessary for realistic world wide labeling is
logically impossible for IPv6, 300 being a lot larger than 128, and
if it were, would result in technically unachievable routing table
sizes. Even allocating, say, 20 bits, if that were possible, would
impossibly multiply table sizes by a million.
Allocating low bits also has problems. There are technical proposals
that use the bottom 64 bits in a manner incompatible with their use
for labels [RFC 2374]. So it would probably have to be "middle bits"
(actually low bits of the upper half). As with IPv4, it would be
impossible to enforce this world wide. If it were possible, one or
two bits could be allocated there, which would be clearly inadequate.
4.3. PICS Labels
PICS Labels (Platform for Internet Content Selection) is a
generalized system for providing "ratings" for Internet accessible
material. The PICS documents [PICS] should be consulted for details.
In general, PICS assumes an arbitrarily large number of rating
services and rating systems. Each service and system is identified
by a URL.
It would be quite reasonable to have multiple PICS services that, in
the aggregate, provided 300 bits of label information or more. There
could be a PICS service for every community of interest. This sort
of technology is really the only reasonable way to make
categorizations or labelings of material available in a diverse and
dynamic world.
While such PICS label services could be used to distribute government
promulgated censorship categories, for example, it is not clear how
this is any worse than government censorship via national firewalls.
A PICS rating system is essentially a definition of one or more
dimensions and the numeric range of the values that can be assigned
in each dimension to a rated object. A service is a source of labels
where a label includes actual ratings. Ratings are either specific
or generic. A specific rating applies only to the material at a
particular URL [RFC 2396] and does not cover anything referenced from
it, even included image files. A generic rating applies to the
specified URL and to all URLs for which the stated URL is a prefix.
A simplified example label might look like the following:
(PICS-1.1 "http://movie-rating-service.example.net"
labels for "ftp://movies.example.sex/raunchy-movie"
ratings (sex 6 violence 1 language 8 drugs 2 Satanism 0))
Machine readable rating system descriptions include the range of
values and set of dimensions provided. Additional information, such
as beginning and ending time of validity, can be incorporated into
labels.
Labels can currently be made available in three ways: (1) embedded in
HTML, (2) provided with data in an HTTP response, and (3) separately
from a third party. If content is required to have labels embedded
in it or transmitted by the source when data is returned, as in the
first two ways listed above, it raises the problems of categorization
granularity and forced speech. However, if used in the third way
whereby a separate party determines and provides labels for content,
and users are free to select whatever such third party or parties
they wish to consult, it can support a myriad of categories, editors,
and evaluators to exist in parallel.
Digital signatures are available to secure PICS Labels [PICS].
5. Security Considerations
Any labeling or categorization scheme must assume that there will be
deliberate attempts to cause data to be incorrectly labeled and
incorrectly categorized. This might be due to some perceived
advantage of particular labeling or merely to disrupt the system.
After all, if sources would always accurately and conveniently label
sent information, security would be much easier [RFC 3514]. Such
enforceability considerations are discussed in conjunction with the
various mechanisms mentioned in this document.
6. Conclusions
The concept that a single top level domain name, such as .sex, or a
single IP address bit, could be allocated and become the mandatory
home of "adult" or "offensive" material world wide is legal and
technical nonsense.
Global agreement on what sort of material should be in such a ghetto
is impossible. In the world wide context, the use of a single
category or small number of categories is absurd. The implementation
of a reasonable size label that could encompass the criterion of the
many communities of the world, such as 300 bits, is technically
impossible at the domain name or IP address level and will remain so
for the foreseeable future. Besides technical impossibility, such a
mandate would be an illegal forcing of speech in some jurisdictions,
as well as cause severe linguistic problems for domain or other
character string names.
However, the concept of a plethora of independent reviewers, some of
which might be governmental agencies, and the ability of those
accessing information to select and utilize ratings assigned by such
reviewers, is possible.
7. References
7.1. Normative References
[PICS] Platform for Internet Content Selection PICS 1.1
Rating Services and Rating Systems -- and Their
Machine Readable Descriptions <http://www.w3.org/TR/
REC-PICS-services>, October 1996.
PICS 1.1 Label Distribution -- Label Syntax and
Communication Protocols <http://www.w3.org/TR/REC-
PICS-labels>, October 1996.
PICSRules 1.1 Specification
<http://www.w3.org/TR/REC-PICSRules>, December 1997.
PICS Signed Labels (DSIG) 1.0 Specification
<http://www.w3.org/TR/REC-DSig-label/>, May 1998.
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC 977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996.
[RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC 2374] Hinden, R., O’Dell, M. and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format", RFC 2374,
July 1998.
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC 2810] Kalt, C., "Internet Relay Chat: Architecture", RFC
2810, April 2000.
[RFC 2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC 2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC 2980] Barber, S., "Common NNTP Extensions", RFC 2980,
October 2000.
7.2. Informative References
[BT] "British Telecom comments to U.S. Commerce
Department", February 20, 1998,
<http://www.ntia.doc.gov/ntiahome/domainname/
130dftmail/BT.htm>
[CDA] "Reno v. American Civil Liberties Union", 117 S.Ct.
2329, June 26, 1997,
[COPAREPORT] "Final Report of the COPA Commission to the U.S.
Congress", October 20, 2000,
<http://www.copacommission.org/report/
newtopleveldomain.shtml>
[GAO] "GAO Report OGC-00-33R", July 7, 2000,
<http://www.gao.gov/new.items/og00033r.pdf>
[GTLD-MOU] "GTLD-MOU Policy Oversight committee RFC 97-02",
September 13, 1997,
<http://www.gtld-mou.org/docs/notice-97-02.html>
[HOUSEREPORT] "U.S. House Commerce Committee report", 105th
Congress, October 5, 1998.
<http://www.epic.org/free_speech/censorship/
hr3783-report.html>
[ICM-REGISTRY] "Request for reconsideration from ICM Registry to
ICANN", December 15, 2000,
<http://www.icann.org/committees/reconsideration/
icm-request-16dec00.htm>
[LIEBERMAN] "Testimony of Senator Joe Lieberman before Children’s
Online Protection Act Commission", June 8, 2000,
<http://www.senate.gov/~lieberman/press/00/06/
2000608958.html>
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1715] Huitema, C., "The H Ratio for Address Assignment
Efficiency", RFC 1715, November 1994.
[RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC 2535] Eastlake, 3rd, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC 2606] Eastlake, 3rd, D. and A. Panitz, "Reserved Top Level