idnits 2.17.1 draft-eastlake-linksectos-01.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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 24 has weird spacing: '... to the autho...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (14 May 1993) is 11304 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Link Security TOS Donald Eastlake, III 3 15 November 1992 4 Expires 14 May 1993 6 Physical Link Security Type of Service 8 Abstract 10 This draft proposes a type of service (TOS) to request maximum 11 physical link security. This would be an addition to the types of 12 service enumerated in RFC 1349: Type of Service in the Internet 13 Protocol Suite. This TOS would request the network to provide what 14 protection it can against surreptitious observation by outside agents 15 of traffic so labeled. The purpose is protection against traffic 16 analysis and as an additional possible level of data confidentiality. 17 This TOS is consistent with all other defined types of service in 18 that it is based on physical link characteristics and will not 19 provide any particular guaranteed level of service. 21 This draft is intended to be submitted to the RFC editor as a 22 Proposed Standard. Distribution of this document is unlimited. 24 Please send any comments to the author, Donald Eastlake, III, 25 . 27 Status 29 This document is an Internet Draft. Internet Drafts are working 30 documents of the Internet Engineering Task Force (IETF), its Areas, 31 and its Working Groups. Note that other groups may also distribute 32 working documents as Internet Drafts. 34 Internet Drafts are draft documents valid for a maximum of six 35 months. Internet Drafts may be updated, replaced, or obsoleted by 36 other documents at any time. It is not appropriate to use Internet 37 Drafts as reference material or to cite them other than as a 38 ``working draft'' or ``work in progress.'' Please check the 1id- 39 abstracts.txt listing contained in the internet-drafts Shadow 40 Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 41 ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any 42 Internet Draft. 44 This draft expires 14 May 1993 46 1. Nature of Requirement 48 This proposal addresses two potential security requirements: 49 resistance to traffic analysis and confidentiality. These are 50 described in the two subsections below followed by a discussion of 51 why links have different levels of physical security so that it is 52 meaningful to request that more secure links by used. 54 1.1 Traffic Analysis 56 At this time all Internet Protocol (IP) packets must have most of 57 their header information, including the from and to address, in the 58 clear. This is required for routers to properly handle the traffic 59 even if a higher level protocol fully encrypts all bytes in the 60 packet after the IP header. This renders even end-to-end encrypted 61 IP packets subject to traffic analysis if the data stream can be 62 observed. While traffic statistics are normally less sensitive than 63 the data content of packets, in some cases activities of hosts or 64 users are deducible from traffic information. 66 It is essential that routers have access to header information, so it 67 is hard to protect traffic statistics from an entity inside the 68 network. However, use of more secure physical links will make 69 traffic observation by entities outside of the network more difficult 70 thus improving protection from traffic analysis. 72 No doubt users would like to be able to request a guaranteed level of 73 link security, just as they would like to be able to request a 74 guaranteed bandwidth or delay through the network. However, such 75 guarantees require a resource reservation and/or policy routing 76 scheme and are beyond the scope of the TOS facility. 78 Although the TOS field is provided in all current Internet packets 79 and routing based on TOS is provided in routing protocols such as 80 OSPF, there is no chance that all of the Internet will implement the 81 proposed additional TOS anytime in the foreseeable future. 82 Nevertheless, users concerned about traffic analysis need to be able 83 to request that the physical security of the links over which their 84 packets will be pass be maximized in preference to other link 85 characteristics. The proposed TOS provides this capability. 87 1.2 Confidentiality 89 Use of physical links with greater physical security provides a layer 90 of protection for the confidentiality of the data in the packets as 91 well as traffic analysis protection. If the content of the packets 92 are otherwise protected by end-to-end encryption, using secure links 93 makes it harder for an external adversary to obtain the encrypted 94 data to attack. If the content of the packets is unencrypted plain 95 text, secure links may provide the only protection of data 96 confidentiality. 98 There are cases where end-to-end encryption can not be used. 99 Examples include paths which incorporate links within nations which 100 severely restrict encryption, such as France, or which incorporate an 101 amateur radio link, where encryption is prohibited. In these cases, 102 link security is generally the only type of security available. The 103 proposed TOS will provide a way of requesting the best that the 104 network can do for the confidentiality of such unencrypted data. 106 This TOS is required for improved confidentiality, especially in 107 cases where encryption can not be used, despite the fact that it does 108 not provide the guarantees that many users would like. See 109 discussion at the end of the Traffic Analysis section above. 111 1.3 Link Physical Security Characteristics 113 Physical links differ widely in their susceptibility to surreptitious 114 observation of the traffic flowing over them. For example: 116 1) Land line media is usually harder to intercept than radio 117 broadcast media. 119 2) Between radio broadcast media, spread spectrum, or other low 120 probability of intercept systems, are harder to intercept than normal 121 broadcast systems. At the other extreme, systems with a large 122 footprint on the earth, such as some satellite down links, may be 123 particularly accessible. 125 3) Between land lines, point to point systems are generally harder to 126 intercept than multi-point systems such as Ethernet or FDDI. 128 4) Fiber optic land lines are generally harder to intercept than 129 metallic paths because fiber is harder to tap. 131 5) A secure land line, such as one in pressurized conduit with 132 pressure alarms or one installed so as to be observable by guards, is 133 harder to intercept than an unsecured land line. 135 6) An encrypted link would be preferable to an unencrypted link 136 because, even if it was intercepted, it would be much more difficult 137 to obtain any useful information. 139 The above comparisons show that there are significant real 140 differences between the security of the physical links in use in the 141 Internet. Choosing links where it is hard for an outside observer to 142 observe the traffic improves confidentiality and protection against 143 traffic analysis. 145 2. Specification 147 The value 15 decimal (F hex) in the four-bit Type of Service IP 148 header field requests routing the packet to minimize the chance of 149 surreptitious observation of its contents by agents external to the 150 network. 152 3. Note on Choice of TOS Value 154 The value 15 is at the maximum hamming distance from existing TOS 155 values. In addition, although the TOS field is no longer bit 156 encoded, this value is chosen so that it is binarily convenient to 157 specify any pair of the five defined TOS attributes should it be 158 decided to make such a pair a recognized TOS. The exclusive-or 159 (i.e., bitwise addition without carry) of any pair of the five TOS 160 values produces a new value not presently used for a defined TOS 161 which could be used to specify the combination of the two types of 162 service indicated by the values that were so combined. 164 4. Implementation 166 This TOS can be implemented in routing systems that offer TOS based 167 routing (as can be done with OSPF, see RFCs 1245 through 1248) by 168 assigning costs to links. Establishing the "cost" for different 169 links for this TOS is a local policy function. 171 In principle services are incomparable when criterion such as those 172 given in the Nature of Requirement section above conflict. For 173 example a choice between an encrypted broadcast system and an 174 unencrypted fiber optic land line. In practice, link encryption 175 would probably dominate all other forms of protection and physical 176 security as mentioned in criterion 5 above would dominate other land 177 line distinctions. 179 An example of costs for a hypothetical router would be as follows: 181 Cost Type 182 1 Strong encryption with secure key distribution 183 2 Physically secure point-to-point line 184 6 Typical point-to-point line 185 8 Typical local multi-point media 186 12 Metropolitan area multi-point media 187 24 Local radio broadcast 188 32 Satellite link 190 It should be noted that routing algorithms typically compute the sum 191 of the costs of the links. For this particular type of service, the 192 product of the link probabilities of secure transmission would be 193 more appropriate. However, the same problem is present for the high 194 reliability TOS and the use of a sum is an adequate approximation for 195 most uses. 197 It should also be noted that using costs such as the sample given 198 above could result in using many more links than if the default class 199 of service were requested. For example, over 50 highly secure links 200 where two insecure links, such as a satellite hop and a radio link, 201 might otherwise have served. 203 Security Considerations 205 The entirety of this draft concerns an Internet Protocol Type of 206 Service to request maximum physical link security against 207 surreptitious interception. 209 Author's Address 211 Donald E. Eastlake, III 212 PO Box N, MIT Branch PO 213 Cambridge, MA 02139 USA 215 phone: +1 508 486 2358 217 email: dee@ranger.enet.dec.com 219 Expiration 221 This draft expires 14 May 1993.