idnits 2.17.1 draft-rfced-info-molitor-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1996) is 10115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 91, but not defined ** Obsolete normative reference: RFC 1038 (ref. '2') (Obsoleted by RFC 1108) Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Doty 3 INTERNET-DRAFT Network Systems Corp. 4 Category: Informational A. Molitor 5 Network Systems Corp. 6 August 1996 8 Proposed Mechanism for Self-Labeling of Content 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a 23 "working draft" or "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the internet-drafts Shadow 27 Directories on: 29 ftp.is.co.za (Africa) 30 nic.nordu.net (Europe) 31 ds.internic.net (US East Coast) 32 ftp.isi.edu (US West Coast) 33 munnari.oz.au (Pacific Rim) 35 Introduction 37 The wide-spread availability of information on the Internet which is 38 deemed by some to contain objectionable content has led to calls by 39 governmental and other bodies for a mandatory content label. It is 40 suggested that the existing IP Security Options might be used as a 41 method for self regulation by individuals offering information to the 42 Internet community. It is further suggested that the options would 43 allow a content labeling analogous to that used by the Motion Picture 44 Industry (G, PG, R, NC-17) and television broadcasters (Adult 45 Situations, Violence, Nudity, etc.). Since these IP options are well 46 understood by the technical community, such a mechanism of self- 47 labeling would be compatible with existing, deployed internetworking 48 equipment. 50 The naming of the various ratings and content categories is 51 undeniably USA-centric, for which the authors apologize. We hope to 52 define the terms sufficiently to make the meaning clear to the global 53 readership. 55 Definitions 57 Herein the word 'provider' or 'content provider' refers to the 58 originator of a datagram. The model here is a host providing 59 information content via any of a variety of possible protocols, to 60 users of the Internet at large, either for a fee, or not. 62 The word 'local authority' is meant relative to the recipient of a 63 datagram, and is intended to mean an authority local to that 64 recipient. The model here is the campus network administration, or 65 an Internet Service Provider through which a customer of a content 66 provider gains Internet access. 68 General Content Label 70 The Basic Security Option (BSO) [1] describes a mechanism for 71 labeling information according to military classification level 72 (Unclassified, Confidential, Secret, or Top Secret). It is proposed 73 that this field be used to label information according to the 74 appropriateness of the audience: G (General audience, including small 75 children), PG (Parental Guidance suggested for non-adolescent 76 children), R (Restricted to adults), or NC-17 (inappropriate for 77 children under the age of maturity). Since IP is globally deployed, 78 and since opinions of what is and is not appropriate do vary across 79 the globe, it is worth pointing out that this re-interpretation of 80 the BSO provides a mechanism for agents to attach that agent's 81 rating. In essence, this permits an opinion of the probable content 82 of the payload to be attached to the datagram, which the recipient 83 may or may not choose to examine. It is therefore quite by design 84 that some information about the rating authority be included with the 85 rating information. The format of the Basic Security Option is shown 86 in Figure 1. The Basic Security Option has an assigned value of 0x82 87 (decimal 130). 89 +------------+------------+------------+-------------//----------+ 90 | 10000010 | XXXXXXXX | SSSSSSSS | AAAAAAA[1] AAAAAAA0 | 91 | | | | [0] | 92 +------------+------------+------------+-------------//----------+ 93 TYPE = 130 LENGTH CLASSIFICATION PROTECTION 94 LEVEL AUTHORITY 95 FLAGS 97 Figure 1. The Basic Security Option 99 To maximize the compatibility with existing deployed equipment, it is 100 suggested that the same mappings be used that are currently defined 101 for classification levels. The mappings defined in [1] are shown in 102 Figure 2, along with the suggested new content labels. It is 103 suggested that the obsolete mappings as specified in [2] be used for 104 self rating, to avoid possible confusion with datagrams containing an 105 actual security classification level. 107 Old Label New Label Value 108 ------------ --------- ----- 109 Unclassified G 0x55 110 Confidential PG 0x7a 111 Secret R 0xad 112 Top Secret NC-17 0x3d 114 Figure 2. Specific Definitions for Label Values 116 [1] defined a Protection Authority Flag (PAF) that represented the 117 classifying agency. It is suggested that this field be used to 118 specify the identify of the rating agency that determined the content 119 label. Currently, it is expected that most information labeled will 120 be self-labeled (i.e. the content label will be assigned by the 121 content provider); however, data could certainly be labeled by other 122 agents, for example private companies who label data for a fee, or a 123 local authority. It is suggested that two values be initially 124 defined: 0 (labeled by the content provider) and 1 (labeled by a 125 local authority). 127 It is surely very difficult to determine automatically the content of 128 a datagram, for rating purposes. Thus, datagrams which are not 129 explicitly labeled by the content provider can probably only be 130 usefully be labeled based on the source IP address. However, this is 131 still useful, since a local authority could potentially do the 132 difficult work of mapping a large table of IP addresses into ratings 133 at a location in the network where it can be most easily done. These 134 ratings will then be carried with the packets, and can be very easily 135 checked later, where the entire mapping table would be very 136 inconvenient to manage. 138 Specific Content Label 140 The Extended Security Option (ESO) can be used to add additional 141 content information. An ESO consists of a option code, 0x85, followed 142 by a one octet length field, followed by a one octet 'source' ID, and 143 lastly a bit field consisting of a variable number of octets, shown 144 below as simply additional security information. More than one ESO 145 may be present in an IP header. 147 +------------+------------+------------+-------//---------+ 148 | 10000101 | 000LLLLL | AAAAAAAA | add sec info | 149 +------------+------------+------------+-------//---------+ 150 TYPE = 133 LENGTH SOURCE ID ADDITIONAL INFO 152 Figure 3. Extended Security Option 154 Widely available implementations of ESO processing software (DNSIX, 155 see [3]) check ESOs found in datagrams arriving on an interface 156 against a table of source IDs configured for that interface. The IDs 157 found in the table identify whether to interpret ESOs with the 158 indicated IDs as Network Layer ESOs (NLESOs), or Auxiliary ESOs 159 (AESOs). This table of ESO source IDs and associated data is called 160 an accreditation table, in the DNSIX documentation. 162 Every ESO found in a datagram must have a source ID found in the 163 interface's table. For AESOs, this is sufficient, and the bit field 164 present in the datagram option is ignored. For NLESOs, the 165 interface's table has a pair of bit fields defined for each NLESO in 166 the table, the so called maximum sensitivity and minimum sensitivity. 167 In order for an NLESO present in the datagram to be valid, all bits 168 set to 1 in the minimum sensitivity must be set to 1 in the datagram, 169 and no bits which are not 1 in the maximum may be set to 1 in the 170 datagram. Any DNSIX implementation must support bit fields up to 128 171 bits wide, so there is quite a lot of room for new content types. 173 We propose that the NLESO could be used to provide finer grained 174 information about content potentially present in the datagram 175 payload. In particular, the positions in the bit field may be used to 176 represent various types of contents, and the source ID to represent 177 the rating authority. Proposed assignments for source ID are limited 178 to the content provider, whoever sent the datagram initially, and a 179 general local authority, typically a rating authority located on the 180 datagram recipient's network providing rating service directly to the 181 recipient. This leaves a large set of other authorities. 183 Rating Authority Source ID 184 ---------------- --------- 185 Content Provider 0x01 186 Local Authority 0x02 188 Figure 4. Specific Definitions for Source IDs 190 For the two rating authorities defined above, the following bit 191 values are defined, borrowing from the cable television industry in 192 the USA: 194 Content Type Bit Value 195 ------------ --------- 196 Language 0x80 197 Violence 0x40 198 Nudity 0x20 199 Adult Themes 0x01 201 Figure 5. Specific Definitions for Content Type Bits 203 Note that the intended semantics of an NLESO here are 'In the opinion 204 of the rating authority indicated by the source ID, the payload of 205 this packet may contain material of the indicated types which may be 206 offensive to some.' 208 It is worth noting here that the BSO, as re-interpreted above, may 209 well provide all the necessary information for a given recipient of 210 datagrams. 212 Examples 214 A packet rated simply as PG-13, by the originator of the packet, 215 would have a BSO of the form: 217 0x82 0x04 0x7a 0x00 219 A packet rated as R by the content provider, with additional 220 information added by a local rating device indicating the possible 221 presence of objectionable violent content would have a BSO: 223 0x82 0x04 0xad 0x00 225 and an NLESO of the form: 227 0x85 0x05 0x02 0x40 0x00 228 An end customer, wishing to restrict access to the most objectionable 229 material would configure their attachment point to the network to be 230 a multi-level interface accepting datagrams marked Unclassified (G, 231 in the interpretation of this document) through Secret (R, in the 232 interpretation of this document), but not Top Secret (NC-17, herein). 233 In addition, the relevant interface would be configured to implicitly 234 label unlabeled datagrams as, perhaps, Unclassified. Thus, only 235 datagrams explicitly labeled as NC-17 would be rejected. 237 If a customer wished to accept G through R content, but wished in 238 addition to reject packets which might contain, say, violent content, 239 the following accreditation table on the attachment interface could 240 be used. 242 Source ID ESO Type Min Max 243 --------- -------- --- --- 244 0x01 NLESO 0x00 0x40 245 0x02 NLESO 0x00 0x40 247 Figure 6. Sample Accreditation Table 248 Oddly enough, by specifying non-zero fields in the Min column, a 249 customer could insist that any ESO-encoded rating must rate the 250 content as having certain objectionable content. No packets without 251 objectionable language, please. This last point truly illustrates 252 that this is a labeling mechanism, not a device for censorship. 254 Interoperability and Deployment 256 Since IP options which are not understood by a host are ignored, this 257 system of ratings is quite transparent to those not taking part in 258 it. 260 Deployment must, by necessity of the culture of the Internet, be 261 entirely voluntary. There are widely deployed DNSIX implementations 262 available in network routers (several router vendors provide the 263 capability, it is probably fair to say that the majority of deployed 264 routers have at least limited DNSIX capability built in, but not 265 enabled by the customer) and DNSIX implementations available for 266 network hosts (Compartmented Mode Workstations offer the possibility 267 of true mixed-content archive servers). Rating by providers would 268 therefore typically be a matter of configuration of existing or 269 widely available equipment. All that is required is the desire to 270 provide rating information, and an agreed upon set of definitions. We 271 hope that this document can serve for the latter. 273 Security Considerations 275 This memo raises no security issues, though it does re-use the IP 276 Security Options. 278 References 280 [1] Kent, S. "U.S. Department of Defense Security Options for the 281 Internet Protocol", RFC 1108, November 1991. 283 [2] St. Johns, M. "Draft revised IP security option", RFC 1038, 284 January 1988. 286 [3] Defense Intelligence Agency, "DNSIX Detailed Design Specification 287 Version 2.1", DDS-2600-5985-91, October 1991. 289 Authors' Addresses 291 Andrew Molitor 292 Network Systems Corp. MS 718 293 7625 Boone Ave. N 294 Brooklyn Park, MN, 55428 296 Ted Doty 297 Network Systems Corp. 298 7600 Boone Ave. N 299 Brooklyn Park, MN, 55428