idnits 2.17.1 draft-ietf-grip-user-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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 are 95 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 16 has weird spacing: '...ormance with...' == Line 24 has weird spacing: '...months and ma...' == Line 25 has weird spacing: '... It is inapp...' == Line 28 has weird spacing: '... To view ...' == Line 31 has weird spacing: '...ons are discu...' == (90 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 31, 1999) is 9217 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) == Missing Reference: 'RFCisp' is mentioned on line 54, but not defined == Missing Reference: 'RFCsshadd' is mentioned on line 55, but not defined == Unused Reference: 'RFC2195' is defined on line 271, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1786 ** Downref: Normative reference to an Informational RFC: RFC 2196 Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Hansen 3 draft-ietf-grip-user-00.txt AT&T Laboratories 4 Valid for six months T. Killalea 5 Verio Northwest 6 January 31, 1999 8 Security Expectations for Internet Service Provider Consumers 10 12 Author's version: 1.5 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 This memo and its companions are discussed on the GRIP working 32 group mailing list, grip-wg[-request]@uu.net. 34 Copyright Notice 36 Copyright (C) The Internet Society (1998). All Rights Reserved. 38 Abstract 40 The purpose of this document is to provide information to the gen- 41 eral Internet community regarding security expectations of Internet Ser- 42 vice Providers (ISPs). 44 It is not the intent of this document to define a set of require- 45 ments that would be appropriate for all ISPs, but rather to provide the 46 community with a framework for discussion of security expectations with 47 current and prospective service providers. 49 This document is written from the perspective of the consumer. 50 Companion documents provide information from the ISP perspective. 52 1. Introduction 54 The purpose of this document, and its companions [RFCisp] and 55 [RFCsshadd], is to express the general Internet community's expectations 56 of Internet Service Providers (ISPs) with respect to security. 58 A goal is that customers could have a framework to facilitate the 59 discussion of security with prospective service providers; regrettably, 60 such a discussion rarely takes place today. 62 Additionally, in informing ISPs of what the community hopes and 63 expects of them, a further goal is to encourage ISPs to become proactive 64 in making security not only a priority, but something to which they 65 point with pride when selling their services. 67 This document is addressed to Internet service purchasing 68 decision-makers (customers). 70 It has been argued that vendors begin to care about security only 71 when prompted by customers. We hope that these documents will encourage 72 both parties to more readily express how much they care about security, 73 and that discussion between the community and its ISPs will be 74 increased. 76 1.1. Conventions Used in this Document 78 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 79 NOT", and "MAY" in this document are to be interpreted as described in 80 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 82 2. Incident Response 84 A Security Incident Response Team (SIRT) is a team that performs, 85 coordinates, and supports the response to security incidents that 86 involve sites within a defined constituency. The Internet community's 87 expectations of SIRTs are described in [BCP21]. 89 2.1. ISPs and Security Incident Response Teams 91 Some ISPs have Security Incident Response Teams (SIRTs). However 92 it should not be assumed that either the ISP's connectivity customers or 93 a site being attacked by a customer of that ISP can automatically avail 94 of the services of the ISP's SIRT. ISP SIRTs are frequently provided as 95 an added-cost service, with the team defining as their constituency only 96 those who specifically subscribe to (and perhaps pay for) Incident 97 Response services. 99 Thus it's important to determine what incident response and secu- 100 rity resources are available to you, and define your incident response 101 escalation chain BEFORE an incident occurs. 103 You should find out if your ISP has a SIRT, and if so what the 104 charter, policies and services of that team are. (This information is 105 best expressed using the SIRT template as shown in Appendix D of 106 [BCP21].) 108 If the ISP doesn't have a SIRT, you should find out what role, if 109 any, they WILL take in incident response. You should also find out if 110 there is any other SIRT whose constituency would include yourself and to 111 whom incidents could be reported. 113 2.2. Assistance with Inbound Security Incidents 115 When a security incident targeting one of their connectivity custo- 116 mers occurs, you should expect your ISP to inform you of the attack, 117 provide assistance to trace the attack, and collect and protect evidence 118 of the incident and guard against its destruction or unintentional 119 announcement. If the event continues, you may ask the ISP to provide 120 logging in order to further diagnose the problem, or to perform filter- 121 ing of certain types of traffic. 123 2.3. Notification of Vulnerabilities and Reporting of Incidents 125 You should expect your ISP to be proactive in notifying you of 126 security vulnerabilities in the services they provide. In addition, as 127 new vulnerabilities in systems and software are discovered, they should 128 indicate whether their services are threatened by these risks. 130 When security incidents occur that affect components of an ISP's 131 infrastructure, your ISP SHOULD promptly report to you: 133 - who is coordinating response to the incident 135 - the vulnerability 137 - how service was affected 139 - what is being done to respond to the incident 141 - whether customer data may have been compromised 143 - what is being done to eliminate the vulnerability 144 - the expected schedule for response, assuming it can be 145 predicted 147 2.4. Contact Information 149 If you need to contact someone at your ISP, you should use the 150 address SECURITY@your.isp.example for network security issues, 151 ABUSE@your.isp.example for issues relating to inappropriate public 152 behaviour, and NOC@your.isp.example for issues relating to network 153 infrastructure. ([RFC2142] states that sites (including ISPs) must 154 maintain these mailboxes, as well as additional mailboxes that are 155 defined for receiving queries and reports relating to specific ser- 156 vices.) Your ISP may also have web site addresses (e.g., 157 http://www.ISP-name-here.net/security/) that you may use to check for 158 expanded details on the above. You should also be able to find contact 159 information for your ISP in Whois and in the routing registry [RFC1786]. 161 2.5. Communication and Authentication 163 You should expect your ISP to have clear policies and procedures on 164 the sharing of information about a security incident with you, other 165 ISPs or SIRTs, with law enforcement, and with the press and the general 166 public. If your jurisdiction permits, you should expect to be able to 167 conduct such communication with your ISP over a secure channel. 169 3. Policies 171 3.1. Security Policy 173 You should expect your ISP to have a policy with regard to privacy, 174 authentication, accountability, application of security patches, availa- 175 bility and violations reporting. 177 A more detailed discussion of Security Policy can be found in the 178 Site Security Handbook [RFC2196]. 180 3.2. Appropriate Use Policy 182 When you establish a contract with your ISP to provide connectivity 183 to the Internet, that contract SHOULD be governed by an Appropriate Use 184 Policy (AUP). The AUP SHOULD clearly identify what you may and may not 185 do on the various components of the system or network, including the 186 type of traffic allowed on the networks. The AUP should be as explicit 187 as possible to avoid ambiguity or misunderstanding. 189 The AUP should be reviewed each time you renew your contract. You 190 should also expect your ISP to proactively notify you as their policies 191 are updated. 193 3.3. Sanctions 195 You should expect the AUP to be clear in stating what sanctions 196 will be enforced in the event of inappropriate behaviour. You should 197 also expect your ISP to be forthcoming in announcing to the community 198 when such sanctions are imposed. 200 3.4. Announcement of Policies 202 You should expect your ISP to publish their security and appropri- 203 ate use policies in a public place such as their web site. This way, 204 the community can be aware of what the ISP considers appropriate and can 205 know what action to expect in the event of inappropriate behaviour. 207 4. Network Infrastructure 209 Your ISP is responsible for managing the network infrastructure of 210 the Internet in such a way that it is: 212 - reasonably resistant to known security vulnerabilities 214 - not easily hijacked by attackers for use in subsequent attacks 216 5. Physical Security 218 If you have co-located equipment at your ISP's facility, the physi- 219 cal security of the installation should be given appropriate considera- 220 tion. This is particularly so for co-located facilities to which people 221 from different organisations and with different security policies have 222 access. Many issues arise surrounding customer access to their co- 223 located equipment. 225 Ideally you and each other customer SHOULD have a fully enclosed 226 locking 'cage', akin to a small room with walls and ceiling of heavy 227 wire mesh fencing, containing the racks in which their equipment is 228 mounted. Each customer would be allowed access to their own cage under 229 escort by one of the ISP's employees, or with keys that grant access 230 specifically to their cage. 232 This assignment of separate cages is expensive in terms of space 233 however, so many ISPs compromise by putting all co-located equipment 234 together in a single machine room, and managing the actions of escorted 235 customers very closely. However this may be insufficient to prevent 236 mishaps such as the accidental disconnection of another customer's 237 equipment. If a single machine room is used then the ISP SHOULD provide 238 separate locking cabinets for each co-location customer in preferance to 239 an open common area. 241 You should expect to always be supervised while in the physical 242 presence of any equipment that is not yours, and should not expect to be 243 allowed to touch, photograph, or examine equipment belonging to another 244 customer. 246 Also of concern is layer 2 security of co-located equipment. Your 247 equipment SHOULD NOT be allowed to share a physical network segment with 248 hosts belonging to anyone else, whether another customer or the ISP 249 themselves. It's common for crackers to exploit weak security or unen- 250 crypted remote logins on co-located customer-owned equipment to take 251 control of that equipment and put it into promiscuous listening mode on 252 the local network segment, thereby potentially compromising the privacy 253 and security of any other devices on that segment. 255 6. References 257 [BCP21] Brownlee, N and E. Guttman, "Expectations for Computer 258 Security Incident Response", BCP 21, RFC 2350, June 1998. 260 [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., 261 Karrenberg, D., Terpstra, M., and J. Yu, "Representation 262 of IP Routing Policies in a Routing Registry (ripe- 263 81++)", RFC 1786, March 1995. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", RFC 2119, March 1997. 268 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles 269 and Functions", RFC 2142, May 1997. 271 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 272 AUTHorize Extension for Simple Challenge/Response", RFC 273 2195, September 1997. 275 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 276 1997. 278 7. Acknowledgements 280 We gratefully acknowledge the constructive comments received from 281 Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall 282 Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, 283 Michael A. Patton, Don Stikvoort and Bill Woodcock. 285 8. Security 287 This entire document discusses security issues. 289 9. Author's Address 291 Tony Hansen 292 AT&T Laboratories 293 Lincroft, NJ 07738 294 USA 296 Phone: +1 732 576-3207 297 E-Mail: tony@att.com 299 Tom Killalea 300 Verio Northwest 301 15400 SE 30th Pl., Ste. 202 302 Bellevue, WA 98007-6546 303 USA 305 Phone: +1 425 649-7417 306 E-Mail: tomk@nw.verio.net 308 10. Full Copyright Statement 310 Copyright (C) The Internet Society (1998). All Rights Reserved. 312 This document and translations of it may be copied and furnished to 313 others, and derivative works that comment on or otherwise explain it or 314 assist in its implmentation may be prepared, copied, published and dis- 315 tributed, in whole or in part, without restriction of any kind, provided 316 that the above copyright notice and this paragraph are included on all 317 such copies and derivative works. However, this document itself may not 318 be modified in any way, such as by removing the copyright notice or 319 references to the Internet Society or other Internet organisations, 320 except as needed for the purpose of developing Internet standards in 321 which case the procedures for copyrights defined in the Internet Stan- 322 dards process must be followed, or as required to translate it into 323 languages other than English. 325 The limited permissions granted above are perpetual and will not be 326 revoked by the Internet Society or its successors or assigns. 328 This document and the information contained herein is provided on 329 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 330 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 331 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 332 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 333 FITNESS FOR A PARTICULAR PURPOSE." 335 This document expires August 1999.