Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-molitor-00.txt < prev next >

Wrap

Text File | 1996-08-21 | 15KB | 392 lines

Network Working Group T. Doty INTERNET-DRAFT Network Systems Corp. Category: Informational A. Molitor Network Systems Corp. August 1996 Proposed Mechanism for Self-Labeling of Content <draft-rfced-info-molitor-00.txt> Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Introduction The wide-spread availability of information on the Internet which is deemed by some to contain objectionable content has led to calls by governmental and other bodies for a mandatory content label. It is suggested that the existing IP Security Options might be used as a method for self regulation by individuals offering information to the Internet community. It is further suggested that the options would allow a content labeling analogous to that used by the Motion Picture Industry (G, PG, R, NC-17) and television broadcasters (Adult Situations, Violence, Nudity, etc.). Since these IP options are well understood by the technical community, such a mechanism of self- labeling would be compatible with existing, deployed internetworking equipment. Doty & Molitor Expires February 1997 [Page 1] Internet-Drafts Content Labeling with IPSO August 1996 The naming of the various ratings and content categories is undeniably USA-centric, for which the authors apologize. We hope to define the terms sufficiently to make the meaning clear to the global readership. Definitions Herein the word 'provider' or 'content provider' refers to the originator of a datagram. The model here is a host providing information content via any of a variety of possible protocols, to users of the Internet at large, either for a fee, or not. The word 'local authority' is meant relative to the recipient of a datagram, and is intended to mean an authority local to that recipient. The model here is the campus network administration, or an Internet Service Provider through which a customer of a content provider gains Internet access. General Content Label The Basic Security Option (BSO) [1] describes a mechanism for labeling information according to military classification level (Unclassified, Confidential, Secret, or Top Secret). It is proposed that this field be used to label information according to the appropriateness of the audience: G (General audience, including small children), PG (Parental Guidance suggested for non-adolescent children), R (Restricted to adults), or NC-17 (inappropriate for children under the age of maturity). Since IP is globally deployed, and since opinions of what is and is not appropriate do vary across the globe, it is worth pointing out that this re-interpretation of the BSO provides a mechanism for agents to attach that agent's rating. In essence, this permits an opinion of the probable content of the payload to be attached to the datagram, which the recipient may or may not choose to examine. It is therefore quite by design that some information about the rating authority be included with the rating information. The format of the Basic Security Option is shown in Figure 1. The Basic Security Option has an assigned value of 0x82 (decimal 130). +------------+------------+------------+-------------//----------+ | 10000010 | XXXXXXXX | SSSSSSSS | AAAAAAA[1] AAAAAAA0 | | | | | [0] | +------------+------------+------------+-------------//----------+ TYPE = 130 LENGTH CLASSIFICATION PROTECTION LEVEL AUTHORITY FLAGS Doty & Molitor Expires February 1997 [Page 2] Internet-Drafts Content Labeling with IPSO August 1996 Figure 1. The Basic Security Option To maximize the compatibility with existing deployed equipment, it is suggested that the same mappings be used that are currently defined for classification levels. The mappings defined in [1] are shown in Figure 2, along with the suggested new content labels. It is suggested that the obsolete mappings as specified in [2] be used for self rating, to avoid possible confusion with datagrams containing an actual security classification level. Old Label New Label Value ------------ --------- ----- Unclassified G 0x55 Confidential PG 0x7a Secret R 0xad Top Secret NC-17 0x3d Figure 2. Specific Definitions for Label Values [1] defined a Protection Authority Flag (PAF) that represented the classifying agency. It is suggested that this field be used to specify the identify of the rating agency that determined the content label. Currently, it is expected that most information labeled will be self-labeled (i.e. the content label will be assigned by the content provider); however, data could certainly be labeled by other agents, for example private companies who label data for a fee, or a local authority. It is suggested that two values be initially defined: 0 (labeled by the content provider) and 1 (labeled by a local authority). It is surely very difficult to determine automatically the content of a datagram, for rating purposes. Thus, datagrams which are not explicitly labeled by the content provider can probably only be usefully be labeled based on the source IP address. However, this is still useful, since a local authority could potentially do the difficult work of mapping a large table of IP addresses into ratings at a location in the network where it can be most easily done. These ratings will then be carried with the packets, and can be very easily checked later, where the entire mapping table would be very inconvenient to manage. Specific Content Label The Extended Security Option (ESO) can be used to add additional content information. An ESO consists of a option code, 0x85, followed by a one octet length field, followed by a one octet 'source' ID, and lastly a bit field consisting of a variable number of octets, shown below as simply additional security information. More than one ESO Doty & Molitor Expires February 1997 [Page 3] Internet-Drafts Content Labeling with IPSO August 1996 may be present in an IP header. +------------+------------+------------+-------//---------+ | 10000101 | 000LLLLL | AAAAAAAA | add sec info | +------------+------------+------------+-------//---------+ TYPE = 133 LENGTH SOURCE ID ADDITIONAL INFO Figure 3. Extended Security Option Widely available implementations of ESO processing software (DNSIX, see [3]) check ESOs found in datagrams arriving on an interface against a table of source IDs configured for that interface. The IDs found in the table identify whether to interpret ESOs with the indicated IDs as Network Layer ESOs (NLESOs), or Auxiliary ESOs (AESOs). This table of ESO source IDs and associated data is called an accreditation table, in the DNSIX documentation. Every ESO found in a datagram must have a source ID found in the interface's table. For AESOs, this is sufficient, and the bit field present in the datagram option is ignored. For NLESOs, the interface's table has a pair of bit fields defined for each NLESO in the table, the so called maximum sensitivity and minimum sensitivity. In order for an NLESO present in the datagram to be valid, all bits set to 1 in the minimum sensitivity must be set to 1 in the datagram, and no bits which are not 1 in the maximum may be set to 1 in the datagram. Any DNSIX implementation must support bit fields up to 128 bits wide, so there is quite a lot of room for new content types. We propose that the NLESO could be used to provide finer grained information about content potentially present in the datagram payload. In particular, the positions in the bit field may be used to represent various types of contents, and the source ID to represent the rating authority. Proposed assignments for source ID are limited to the content provider, whoever sent the datagram initially, and a general local authority, typically a rating authority located on the datagram recipient's network providing rating service directly to the recipient. This leaves a large set of other authorities. Rating Authority Source ID ---------------- --------- Content Provider 0x01 Local Authority 0x02 Figure 4. Specific Definitions for Source IDs For the two rating authorities defined above, the following bit values are defined, borrowing from the cable television industry in the USA: Doty & Molitor Expires February 1997 [Page 4] Internet-Drafts Content Labeling with IPSO August 1996 Content Type Bit Value ------------ --------- Language 0x80 Violence 0x40 Nudity 0x20 Adult Themes 0x01 Figure 5. Specific Definitions for Content Type Bits Note that the intended semantics of an NLESO here are 'In the opinion of the rating authority indicated by the source ID, the payload of this packet may contain material of the indicated types which may be offensive to some.' It is worth noting here that the BSO, as re-interpreted above, may well provide all the necessary information for a given recipient of datagrams. Examples A packet rated simply as PG-13, by the originator of the packet, would have a BSO of the form: 0x82 0x04 0x7a 0x00 A packet rated as R by the content provider, with additional information added by a local rating device indicating the possible presence of objectionable violent content would have a BSO: 0x82 0x04 0xad 0x00 and an NLESO of the form: 0x85 0x05 0x02 0x40 0x00 An end customer, wishing to restrict access to the most objectionable material would configure their attachment point to the network to be a multi-level interface accepting datagrams marked Unclassified (G, in the interpretation of this document) through Secret (R, in the interpretation of this document), but not Top Secret (NC-17, herein). In addition, the relevant interface would be configured to implicitly label unlabeled datagrams as, perhaps, Unclassified. Thus, only datagrams explicitly labeled as NC-17 would be rejected. If a customer wished to accept G through R content, but wished in addition to reject packets which might contain, say, violent content, the following accreditation table on the attachment interface could be used. Doty & Molitor Expires February 1997 [Page 5] Internet-Drafts Content Labeling with IPSO August 1996 Source ID ESO Type Min Max --------- -------- --- --- 0x01 NLESO 0x00 0x40 0x02 NLESO 0x00 0x40 Figure 6. Sample Accreditation Table Oddly enough, by specifying non-zero fields in the Min column, a customer could insist that any ESO-encoded rating must rate the content as having certain objectionable content. No packets without objectionable language, please. This last point truly illustrates that this is a labeling mechanism, not a device for censorship. Interoperability and Deployment Since IP options which are not understood by a host are ignored, this system of ratings is quite transparent to those not taking part in it. Deployment must, by necessity of the culture of the Internet, be entirely voluntary. There are widely deployed DNSIX implementations available in network routers (several router vendors provide the capability, it is probably fair to say that the majority of deployed routers have at least limited DNSIX capability built in, but not enabled by the customer) and DNSIX implementations available for network hosts (Compartmented Mode Workstations offer the possibility of true mixed-content archive servers). Rating by providers would therefore typically be a matter of configuration of existing or widely available equipment. All that is required is the desire to provide rating information, and an agreed upon set of definitions. We hope that this document can serve for the latter. Security Considerations This memo raises no security issues, though it does re-use the IP Security Options. References [1] Kent, S. "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991. [2] St. Johns, M. "Draft revised IP security option", RFC 1038, January 1988. [3] Defense Intelligence Agency, "DNSIX Detailed Design Specification Version 2.1", DDS-2600-5985-91, October 1991. Doty & Molitor Expires February 1997 [Page 6] Internet-Drafts Content Labeling with IPSO August 1996 Authors' Addresses Andrew Molitor Network Systems Corp. MS 718 7625 Boone Ave. N Brooklyn Park, MN, 55428 Ted Doty Network Systems Corp. 7600 Boone Ave. N Brooklyn Park, MN, 55428 Doty & Molitor Expires February 1997 [Page 7]