idnits 2.17.1 draft-ietf-grip-isp-expectations-02.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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (November 1999) is 8929 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) == Unused Reference: 'RFC1834' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC1835' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC2196' is defined on line 481, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DPR1998' ** Downref: Normative reference to an Informational RFC: RFC 1786 ** Downref: Normative reference to an Informational RFC: RFC 1834 ** Downref: Normative reference to an Historic RFC: RFC 1835 ** Downref: Normative reference to an Informational RFC: RFC 2196 ** Obsolete normative reference: RFC 2267 (Obsoleted by RFC 2827) ** Obsolete normative reference: RFC 2476 (Obsoleted by RFC 4409) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Tom Killalea 2 INTERNET-DRAFT neart.org 3 Valid for six months November 1999 5 Security Expectations for Internet Service Providers 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is inappropriate to use Internet 20 Drafts as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 Abstract 35 The purpose of this document is to express the general Internet 36 community's expectations of Internet Service Providers (ISPs) with 37 respect to security. 39 It is not the intent of this document to define a set of requirements 40 that would be appropriate for all ISPs, but rather to raise awareness 41 among ISPs of the community's expectations, and to provide the 42 community with a framework for discussion of security expectations 43 with current and prospective service providers. 45 Table of Contents 46 1 Introduction 47 1.1 Conventions Used in this Document 49 2 Communication 50 2.1 Contact Information 51 2.2 Information Sharing 52 2.3 Secure Channels 53 2.4 Notification of Vulnerabilities and Reporting Incidents 54 2.5 ISPs and Computer Security Incident Response Teams (CSIRTs) 56 3 Appropriate Use Policy 57 3.1 Announcement of Policy 58 3.2 Sanctions 59 3.3 Data Protection 61 4 Network Infrastructure 62 4.1 Registry Data Maintenance 63 4.2 Routing Infrastructure 64 4.3 Ingress Filtering on Source Address 65 4.4 Egress Filtering on Source Address 66 4.5 Route Filtering 67 4.6 Directed Broadcast 69 5 Systems Infrastructure 70 5.1 System Management 71 5.2 No Systems on Transit Networks 72 5.3 Open Mail Relay 73 5.4 Message Submission 75 6 References 77 7 Acknowledgements 79 8 Security Considerations 81 9 Author's Address 83 10 Full Copyright Statement 85 1 Introduction 87 The purpose of this document is to express the general Internet 88 community's expectations of Internet Service Providers (ISPs) with 89 respect to security. This document is addressed to ISPs. 91 By informing ISPs of what the community hopes and expects of them, 92 the community hopes to encourage ISPs to become proactive in making 93 security not only a priority, but something to which they point with 94 pride when selling their services. 96 Under no circumstances is it the intention of this document to 97 dictate business practices. 99 In this document we define ISPs to include organisations in the 100 business of providing Internet connectivity or other Internet 101 services including but not restricted to web hosting services, 102 content providers and e-mail services. We do not include in our 103 definition of an ISP organisations providing those services for their 104 own purposes. 106 1.1 Conventions Used in this Document 108 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 109 and "MAY" in this document are to be interpreted as described in "Key 110 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 112 2 Communication 114 The community's most significant security-related expectations of 115 ISPs relate to the availability of communication channels for dealing 116 with security incidents. 118 2.1 Contact Information 120 ISPs SHOULD adhere to [RFC2142], which defines the mailbox SECURITY 121 for network security issues, ABUSE for issues relating to 122 inappropriate public behaviour and NOC for issues relating to network 123 infrastructure. It also lists additional mailboxes that are defined 124 for receiving queries and reports relating to specific services. 126 ISPs may consider using common URLs for expanded details on the above 127 (e.g., http://www.ISP-name-here.net/security/). 129 In addition, ISPs have a duty to make sure that their contact 130 information, in Whois, in the routing registry [RFC1786] or in any 131 other repository, is complete, accurate and reachable. 133 2.2 Information Sharing 135 ISPs SHOULD have clear policies and procedures on the sharing of 136 information about a security incident with their customers, with 137 other ISPs or CSIRTs, with law enforcement or with the press and 138 general public. 140 ISPs should have processes in place to deal with security incidents 141 that traverse the boundaries between them and other ISPs. 143 2.3 Secure Channels 145 ISPs SHOULD be able to conduct such communication over a secure 146 channel. Note, however, that in some jurisdictions secure channels 147 might not be permitted. 149 2.4 Notification of Vulnerabilities and Reporting of Incidents 151 ISPs SHOULD be proactive in notifying customers of security 152 vulnerabilities in the services they provide. In addition, as new 153 vulnerabilities in systems and software are discovered they should 154 indicate whether their services are threatened by these risks. 156 When security incidents occur that affect components of an ISP's 157 infrastructure the ISP should promptly report to their customers 159 - who is coordinating response to the incident 161 - the vulnerability 163 - how service was affected 165 - what is being done to respond to the incident 167 - whether customer data may have been compromised 169 - what is being done to eliminate the vulnerability 171 - the expected schedule for response, assuming it can be 172 predicted 174 Many ISPs have established procedures for notifying customers of 175 outages and service degradation. It is reasonable for the ISP to use 176 these channels for reporting security-related incidents. In such 177 cases, the customer's security point of contact might not be the 178 person notified. Rather, the normal point of contact will receive 179 the report. Customers should be aware of this and make sure to route 180 such notifications appropriately. 182 2.5 Incident Response and Computer Security Incident Response Teams 183 (CSIRTs) 185 A Computer Security Incident Response Team (CSIRT) is a team that 186 performs, coordinates, and supports the response to security 187 incidents that involve sites within a defined constituency. The 188 Internet community's expectations of CSIRTs are described in 189 "Expectations for Computer Security Incident Response" [RFC2350]. 191 Whether or not an ISP has a CSIRT, they should have a well-advertised 192 way to receive and handle reported incidents from their customers. 193 In addition, they should clearly document their capability to respond 194 to reported incidents, and should indicate if there is any CSIRT 195 whose constituency would include the customer and to whom incidents 196 could be reported. 198 Some ISPs have CSIRTs. However it should not be assumed that either 199 the ISP's connectivity customers or a site being attacked by a 200 customer of that ISP can automatically avail themselves of the 201 services of the ISP's CSIRT. ISP CSIRTs are frequently provided as 202 an added-cost service, with the team defining as their constituency 203 only those who specifically subscribe to (and perhaps pay for) 204 Incident Response services. 206 Thus it's important for ISPs to publish what incident response and 207 security resources they make available to customers, so that the 208 customers can define their incident response escalation chain BEFORE 209 an incident occurs. 211 Customers should find out whether their ISP has a CSIRT, and if so 212 what the charter, policies and services of that team are. This 213 information is best expressed using the CSIRT template as shown in 214 Appendix D of "Expectations for Computer Security Incident Response" 215 [RFC2350]. 217 3 Appropriate Use Policy 219 Every ISP SHOULD have an Appropriate Use Policy (AUP). 221 Whenever an ISP contracts with a customer to provide connectivity to 222 the Internet that contract should be governed by an AUP. The AUP 223 should be reviewed each time the contract is up for renewal, and in 224 addition the ISP should proactively notify customers as policies are 225 updated. 227 An AUP should clearly identify what customers shall and shall not do 228 on the various components of a system or network, including the type 229 of traffic allowed on the networks. The AUP should be as explicit as 230 possible to avoid ambiguity or misunderstanding. For example, an AUP 231 might prohibit IP spoofing. 233 3.1 Announcement of Policy 235 In addition to communicating their AUP to their customers ISPs should 236 publish their policy in a public place such as their web site so that 237 the community can be aware of what the ISP considers appropriate and 238 can know what action to expect in the event of inappropriate 239 behaviour. 241 3.2 Sanctions 243 An AUP should be clear in stating what sanctions will be enforced in 244 the event of inappropriate behaviour. 246 3.3 Data Protection 248 Many jurisdictions have Data Protection Legislation. Where such 249 legislation applies, ISPs should consider the personal data they hold 250 and, if necessary, register themselves as Data Controllers and be 251 prepared to only use the data in accordance with the terms of the 252 legislation. Given the global nature of the Internet ISPs that are 253 located where no such legislation exists should at least familiarise 254 themselves with the idea of Data Protection by reading a typical Data 255 Protection Act (e.g., [DPR1998]). 257 4 Network Infrastructure 259 ISPs are responsible for managing the network infrastructure of the 260 Internet in such a way that it is 262 - reasonably resistant to known security vulnerabilities 264 - not easily hijacked by attackers for use in subsequent attacks 266 4.1 Registry Data Maintenance 268 ISPs are commonly responsible for maintaining the data that is stored 269 in global repositories such as the Internet Routing Registry (IRR) 270 and the APNIC, InterNIC and RIPE databases. Updates to this data 271 should only be possible using strong authentication. 273 ISPs should 'SWIP' (Shared WhoIs Project) the address space that they 274 assign to their customers so that there is more specific contact 275 information for the delegated space. 277 4.2 Routing Infrastructure 279 An ISP's ability to route traffic to the correct destination depends 280 on routing policy as configured in the routing registries [RFC1786]. 281 ISPs should ensure that the registry information that they maintain 282 can only be updated using strong authentication, and that the 283 authority to make updates is appropriately restricted. 285 Due care should also be taken in determining in whose routing 286 announcements you place greater trust when a choice of routes are 287 available to a destination. In the past bogus announcements have 288 resulted in traffic being 'black holed', or worse, hijacked. BGP 289 authentication should be used with routing peers. 291 4.3 Ingress Filtering on Source Address 293 The direction of such filtering is from the edge site (customer) to 294 the Internet. 296 Attackers frequently cover their tracks by using forged source 297 addresses. To divert attention from their own site the source 298 address they choose will generally be from an innocent remote site or 299 indeed from those addresses that are allocated for private Internets 300 [RFC1918]. In addition, forged source addresses are frequently used 301 in spoof-based attacks in order to exploit a trust relationship 302 between hosts. 304 To reduce the incidence of attacks that rely on forged source 305 addresses ISPs should do the following. At the boundary router with 306 each of their customers they should proactively filter all traffic 307 coming from the customer that has a source address of something other 308 than the addresses that have been assigned to that customer. For a 309 more detailed discussion of this topic see [RFC2267]. 311 There are (rare) circumstances where ingress filtering is not 312 currently possible, for example on large aggregation routers that 313 cannot take the additional load of applying packet filters. In 314 addition, such filtering can cause difficulty for mobile users. 315 Hence, while the use of this technique to prevent spoofing is 316 strongly encouraged, it may not always be feasible. 318 In these rare cases where ingress filtering at the interface between 319 the customer and the ISP is not possible, the customer should be 320 encouraged to implement ingress filtering within their networks. In 321 general filtering should be done as close to the actual hosts as 322 possible. 324 4.4 Egress Filtering on Source Address 326 The direction of such filtering is from the Internet to the edge site 327 (customer). 329 There are many applications in widespread use on the Internet today 330 that grant trust to other hosts based only on ip address (e.g., the 331 Berkeley 'r' commands). These are susceptible to IP spoofing, as 332 described in [CA-95.01.IP.spoofing]. In addition, there are 333 vulnerabilities that depend on the misuse of supposedly local 334 addresses, such as 'land' as described in [CA-97.28.Teardrop_Land]. 336 To reduce the exposure of their customers to attacks that rely on 337 forged source addresses ISPs should do the following. At the 338 boundary router with each of their customers they should proactively 339 filter all traffic going to the customer that has a source address of 340 any of the addresses that have been assigned to that customer. 342 The circumstances described in 5.7 in which ingress filtering isn't 343 feasible apply similarly to egress filtering. 345 4.5 Route Filtering 347 Excessive routing updates can be leveraged by an attacker as a base 348 load on which to build a Denial of Service attack. At the very least 349 they will result in performance degradation. 351 ISPs should filter the routing announcements they hear, for example 352 to ignore routes to addresses allocated for private Internets, to 353 avoid bogus routes and to implement "BGP Route Flap Dampening" 354 [RFC2439] and aggregation policy. 356 ISPs should implement techniques that reduce the risk of putting 357 excessive load on routing in other parts of the network. These 358 include 'nailed up' routes, aggressive aggregation and route 359 dampening, all of which lower the impact on others when your internal 360 routing changes in a way that isn't relevant to them. 362 4.6 Directed Broadcast 363 The IP protocol allows for directed broadcast, the sending of a 364 packet across the network to be broadcast on to a specific subnet. 365 Very few practical uses for this feature exist, but several different 366 security attacks (primarily Denial of Service attacks making use of 367 the packet multiplication effect of the broadcast) use it. 368 Therefore, routers connected to a broadcast medium MUST NOT be 369 configured to allow directed broadcasts onto that medium [RFC2644]. 371 5 Systems Infrastructure 373 The way an ISP manages their systems is crucial to the security and 374 reliability of their network. A breach of their systems may 375 minimally lead to degraded performance or functionality, but could 376 lead to loss of data or the risk of traffic being eavesdropped (thus 377 leading to 'man-in-the-middle' attacks). 379 It's widely accepted that it's easier to build secure systems if 380 different services (such as mail, news and web-hosting) are kept on 381 separate systems. 383 5.1 System Management 385 All systems that perform critical ISP functions such as mail, news 386 and web-hosting, should be restricted such that access to them is 387 only available to the administrators of those services. That access 388 should be granted only following strong authentication, and should 389 take place over an encrypted link. Only the ports on which those 390 services listen should be reachable from outside of the ISP's systems 391 networks. 393 ISPs should stay up to date for more secure methods of providing 394 services as they become available (e.g., IMAP/POP AUTHorize Extension 395 for Simple Challenge/Response, [RFC2195]). 397 5.2 No Systems on Transit Networks 399 Systems should not be attached to transit network segments. 401 5.3 Open Mail Relay 403 An SMTP mail server is said to be running as an 'open' mail relay if 404 it is willing to accept and relay to non-local destinations mail 405 messages that do not originate locally (i.e., neither the originator 406 nor the recipient address is local). Such open relays are frequently 407 used by 'spammers' to inject their Unsolicited Bulk E-mail (UBE) 408 while hiding their identity. There are only very limited 409 circumstances in which an administrator can make a justifiable case 410 for leaving a mail relay on the Internet completely open. 412 The processes for restricting relaying are well documented. It's 413 regrettable that some major software vendors ship their Message 414 Transfer Agents (MTAs) with relaying open by default. 416 While this is an issue for the whole community, ISPs should be 417 particularly vigilant in disabling open relaying on mail servers that 418 they manage because their high-bandwidth connectivity makes them the 419 preferred injection point for UBE. 421 ISPs should also strongly encourage their customers to disable open 422 relaying on their mail servers. Sanctions for running an open mail 423 relay should be covered in an ISP's AUP. 425 5.4 Message Submission 427 To facilitate the enforcement of security policy message submission 428 should be done through the MAIL SUBMIT port (587) as discussed in 429 "Message Submission" [RFC2476], rather than through the SMTP port 430 (25). In addition, message submissions should be authenticated using 431 the AUTH SMTP service extension as described in the work in progess 432 called "SMTP Service Extension for Authentication". In this way the 433 SMTP port (25) can be restricted to local delivery only. 435 These two measures not only protect the ISP from serving as a UBE 436 injection point, but also help in tracking accountability for message 437 submission in the case where a customer sends UBE. Furthermore, 438 using the Submit port with SMTP AUTH has additional advantages over 439 IP address-based submission restrictions in that it gives the ISP's 440 customers the flexibility of being able to submit mail even when not 441 connected through the ISP's network (for example, while at work), is 442 more resistant to spoofing, and can be upgraded to newer 443 authentication mechanisms as they become available. 445 6 References 447 [CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal 448 Connections", ftp://info.cert.org/pub/cert_advisories/ 450 [CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks", 451 ftp://info.cert.org/pub/cert_advisories/ 453 [DPR1998] The UK "Data Protection Act 1998 (c. 29)", 454 http://www.hmso.gov.uk/acts/acts1998/19980029.htm 456 [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., 457 Karrenberg, D., Terpstra, M., and J. Yu, "Representation of IP 458 Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, 459 March 1995. 461 [RFC1834] Gargano, J., and K. Weiss, "Whois and Network Information 462 Lookup Service", RFC 1834, August 1995. 464 [RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, 465 "Architecture of the WHOIS++ service", RFC 1835, August 1995. 467 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 468 J., and E. Lear, "Address Allocation for Private Internets", BCP 5, 469 RFC 1918, February 1996. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", RFC 2119, March 1997. 474 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 475 Functions", RFC 2142, May 1997. 477 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 478 AUTHorize Extension for Simple Challenge/Response", RFC 2195, 479 September 1997. 481 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 482 1997. 484 [RFC2267] Ferguson, P., and D. Senie, "Network Ingress Filtering: 485 Defeating Denial of Service Attacks which employ IP Source 486 Address Spoofing", RFC 2267, January 1998. 488 [RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer 489 Security Incident Response", RFC 2350, June 1998. 491 [RFC2439] Chandra R., Govindan R., and C. Villamizar, "BGP Route 492 Flap Damping", RFC 2439, November 1998. 494 [RFC2476] Gellens R., and J. Klensin, "Message Submission", 495 RFC 2476, December 1998. 497 [RFC2644] 498 Senie D., "Changing the Default for Directed Broadcasts in 499 Routers", RFC 2644, August 1999. 501 7 Acknowledgements 503 I gratefully acknowledge the constructive comments received from 504 Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall 505 Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, 506 Michael A. Patton, Don Stikvoort and Bill Woodcock. 508 8 Security Considerations 510 This entire document discusses security issues. 512 9 Author's Address 514 Tom Killalea 515 1516 2nd Ave 516 Seattle, WA 98101 517 USA 519 Phone: +1 206 266-2196 520 E-Mail: tomk@neart.org 522 10 Full Copyright Statement 524 Copyright (C) The Internet Society (1999). All Rights Reserved. 526 This document and translations of it may be copied and furnished to 527 others, and derivative works that comment on or otherwise explain it 528 or assist in its implmentation may be prepared, copied, published and 529 distributed, in whole or in part, without restriction of any kind, 530 provided that the above copyright notice and this paragraph are 531 included on all such copies and derivative works. However, this 532 document itself may not be modified in any way, such as by removing 533 the copyright notice or references to the Internet Society or other 534 Internet organisations, except as needed for the purpose of 535 developing Internet standards in which case the procedures for 536 copyrights defined in the Internet Standards process must be 537 followed, or as required to translate it into languages other than 538 English. 540 The limited permissions granted above are perpetual and will not be 541 revoked by the Internet Society or its successors or assigns. 543 This document and the information contained herein is provided on an 544 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 545 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 546 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 547 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 548 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 550 This document expires May 22, 2000.