idnits 2.17.1 draft-ietf-grip-isp-expectations-06.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 (September 2000) is 8617 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 475, but no explicit reference was found in the text == Unused Reference: 'RFC1835' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC2196' is defined on line 495, 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 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2476 (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 2554 (Obsoleted by RFC 4954) Summary: 13 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 September 2000 5 Recommended Internet Service Provider Security Services and Procedures 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 (2000). All Rights Reserved. 33 Abstract 35 The purpose of this document is to express what the engineering 36 community as represented by the IETF expects of Internet Service 37 Providers (ISPs) with 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 what the engineering 88 community as represented by the IETF expects of Internet Service 89 Providers (ISPs) with respect to security. This document is 90 addressed to ISPs. 92 By informing ISPs of what this community hopes and expects of them, 93 the community hopes to encourage ISPs to become proactive in making 94 security not only a priority, but something to which they point with 95 pride when selling their services. 97 Under no circumstances is it the intention of this document to 98 dictate business practices. 100 In this document we define ISPs to include organisations in the 101 business of providing Internet connectivity or other Internet 102 services including but not restricted to web hosting services, 103 content providers and e-mail services. We do not include in our 104 definition of an ISP organisations providing those services for their 105 own purposes. 107 This document is offered as a set of recommendations to ISPs 108 regarding what security and attack management arrangements should be 109 supported, and as advice to users regarding what they should expect 110 from a high quality service provider. It is in no sense normative in 111 its own right. In time it is likely to become dated, and other 112 expectations may arise. However, it does represent a snapshot of the 113 recommendations of a set of professionals in the field at a given 114 point in the development of the Internet and its technology. 116 1.1 Conventions Used in this Document 118 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 119 and "MAY" in this document are to be interpreted as described in "Key 120 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 122 2 Communication 124 The community's most significant security-related expectations of 125 ISPs relate to the availability of communication channels for dealing 126 with security incidents. 128 2.1 Contact Information 130 ISPs SHOULD adhere to [RFC2142], which defines the mailbox SECURITY 131 for network security issues, ABUSE for issues relating to 132 inappropriate public behaviour and NOC for issues relating to network 133 infrastructure. It also lists additional mailboxes that are defined 134 for receiving queries and reports relating to specific services. 136 ISPs may consider using common URLs for expanded details on the above 137 (e.g., http://www.ISP-name-here.net/security/). 139 In addition, ISPs have a duty to make sure that their contact 140 information, in Whois, in routing registries [RFC1786] or in any 141 other repository, is complete, accurate and reachable. 143 2.2 Information Sharing 145 ISPs SHOULD have clear policies and procedures on the sharing of 146 information about a security incident with their customers, with 147 other ISPs, with Incident Response Teams, with law enforcement or 148 with the press and general public. 150 ISPs should have processes in place to deal with security incidents 151 that traverse the boundaries between them and other ISPs. 153 2.3 Secure Channels 155 ISPs SHOULD be able to conduct such communication over a secure 156 channel. Note, however, that in some jurisdictions secure channels 157 might not be permitted. 159 2.4 Notification of Vulnerabilities and Reporting of Incidents 161 ISPs SHOULD be proactive in notifying customers of security 162 vulnerabilities in the services they provide. In addition, as new 163 vulnerabilities in systems and software are discovered they should 164 indicate whether their services are threatened by these risks. 166 When security incidents occur that affect components of an ISP's 167 infrastructure the ISP should promptly report to their customers 169 - who is coordinating response to the incident 171 - the vulnerability 173 - how service was affected 175 - what is being done to respond to the incident 177 - whether customer data may have been compromised 179 - what is being done to eliminate the vulnerability 181 - the expected schedule for response, assuming it can be 182 predicted 184 Many ISPs have established procedures for notifying customers of 185 outages and service degradation. It is reasonable for the ISP to use 186 these channels for reporting security-related incidents. In such 187 cases, the customer's security point of contact might not be the 188 person notified. Rather, the normal point of contact will receive 189 the report. Customers should be aware of this and make sure to route 190 such notifications appropriately. 192 2.5 Incident Response and Computer Security Incident Response Teams 193 (CSIRTs) 195 A Computer Security Incident Response Team (CSIRT) is a team that 196 performs, coordinates, and supports the response to security 197 incidents that involve sites within a defined constituency. The 198 Internet community's expectations of CSIRTs are described in 199 "Expectations for Computer Security Incident Response" [RFC2350]. 201 Whether or not an ISP has a CSIRT, they should have a well-advertised 202 way to receive and handle reported incidents from their customers. 203 In addition, they should clearly document their capability to respond 204 to reported incidents, and should indicate if there is any CSIRT 205 whose constituency would include the customer and to whom incidents 206 could be reported. 208 Some ISPs have CSIRTs. However it should not be assumed that either 209 the ISP's connectivity customers or a site being attacked by a 210 customer of that ISP can automatically avail themselves of the 211 services of the ISP's CSIRT. ISP CSIRTs are frequently provided as 212 an added-cost service, with the team defining as their constituency 213 only those who specifically subscribe to (and perhaps pay for) 214 Incident Response services. 216 Thus it's important for ISPs to publish what incident response and 217 security resources they make available to customers, so that the 218 customers can define their incident response escalation chain BEFORE 219 an incident occurs. 221 Customers should find out whether their ISP has a CSIRT, and if so 222 what the charter, policies and services of that team are. This 223 information is best expressed using the CSIRT template as shown in 224 Appendix D of "Expectations for Computer Security Incident Response" 225 [RFC2350]. 227 3 Appropriate Use Policy 229 Every ISP SHOULD have an Appropriate Use Policy (AUP). 231 Whenever an ISP contracts with a customer to provide connectivity to 232 the Internet that contract should be governed by an AUP. The AUP 233 should be reviewed each time the contract is up for renewal, and in 234 addition the ISP should proactively notify customers as policies are 235 updated. 237 An AUP should clearly identify what customers shall and shall not do 238 on the various components of a system or network, including the type 239 of traffic allowed on the networks. The AUP should be as explicit as 240 possible to avoid ambiguity or misunderstanding. For example, an AUP 241 might prohibit IP spoofing. 243 3.1 Announcement of Policy 245 In addition to communicating their AUP to their customers ISPs should 246 publish their policy in a public place such as their web site so that 247 the community can be aware of what the ISP considers appropriate and 248 can know what action to expect in the event of inappropriate 249 behaviour. 251 3.2 Sanctions 253 An AUP should be clear in stating what sanctions will be enforced in 254 the event of inappropriate behaviour. 256 3.3 Data Protection 258 Many jurisdictions have Data Protection Legislation. Where such 259 legislation applies, ISPs should consider the personal data they hold 260 and, if necessary, register themselves as Data Controllers and be 261 prepared to only use the data in accordance with the terms of the 262 legislation. Given the global nature of the Internet ISPs that are 263 located where no such legislation exists should at least familiarise 264 themselves with the idea of Data Protection by reading a typical Data 265 Protection Act (e.g., [DPR1998]). 267 4 Network Infrastructure 269 ISPs are responsible for managing the network infrastructure of the 270 Internet in such a way that it is 272 - reasonably resistant to known security vulnerabilities 274 - not easily hijacked by attackers for use in subsequent attacks 276 4.1 Registry Data Maintenance 278 ISPs are commonly responsible for maintaining the data that is stored 279 in global repositories such as the Internet Routing Registry (IRR) 280 and the APNIC, ARIN and RIPE databases. Updates to this data should 281 only be possible using strong authentication. 283 ISPs should publicly register the address space that they assign to 284 their customers so that there is more specific contact information 285 for the delegated space. 287 4.2 Routing Infrastructure 289 An ISP's ability to route traffic to the correct destination may 290 depend on routing policy as configured in routing registries 291 [RFC1786]. If so, and if the registry supports it, they should 292 ensure that the registry information that they maintain can only be 293 updated using strong authentication, and that the authority to make 294 updates is appropriately restricted. 296 Due care should also be taken in determining in whose routing 297 announcements you place greater trust when a choice of routes are 298 available to a destination. In the past bogus announcements have 299 resulted in traffic being 'black holed', or worse, hijacked. 301 BGP authentication [RFC2385] SHOULD be used with routing peers. 303 4.3 Ingress Filtering on Source Address 305 The direction of such filtering is from the edge site (customer) to 306 the Internet. 308 Attackers frequently cover their tracks by using forged source 309 addresses. To divert attention from their own site the source 310 address they choose will generally be from an innocent remote site or 311 indeed from those addresses that are allocated for private Internets 312 [RFC1918]. In addition, forged source addresses are frequently used 313 in spoof-based attacks in order to exploit a trust relationship 314 between hosts. 316 To reduce the incidence of attacks that rely on forged source 317 addresses ISPs should do the following. At the boundary router with 318 each of their customers they should proactively filter all traffic 319 coming from the customer that has a source address of something other 320 than the addresses that have been assigned to that customer. For a 321 more detailed discussion of this topic see [RFC2827]. 323 There are (rare) circumstances where ingress filtering is not 324 currently possible, for example on large aggregation routers that 325 cannot take the additional load of applying packet filters. In 326 addition, such filtering can cause difficulty for mobile users. 327 Hence, while the use of this technique to prevent spoofing is 328 strongly encouraged, it may not always be feasible. 330 In these rare cases where ingress filtering at the interface between 331 the customer and the ISP is not possible, the customer should be 332 encouraged to implement ingress filtering within their networks. In 333 general filtering should be done as close to the actual hosts as 334 possible. 336 4.4 Egress Filtering on Source Address 338 The direction of such filtering is from the Internet to the edge site 339 (customer). 341 There are many applications in widespread use on the Internet today 342 that grant trust to other hosts based only on ip address (e.g., the 343 Berkeley 'r' commands). These are susceptible to IP spoofing, as 344 described in [CA-95.01.IP.spoofing]. In addition, there are 345 vulnerabilities that depend on the misuse of supposedly local 346 addresses, such as 'land' as described in [CA-97.28.Teardrop_Land]. 348 To reduce the exposure of their customers to attacks that rely on 349 forged source addresses ISPs should do the following. At the 350 boundary router with each of their customers they should proactively 351 filter all traffic going to the customer that has a source address of 352 any of the addresses that have been assigned to that customer. 354 The circumstances described in 4.3 in which ingress filtering isn't 355 feasible apply similarly to egress filtering. 357 4.5 Route Filtering 359 Excessive routing updates can be leveraged by an attacker as a base 360 load on which to build a Denial of Service attack. At the very least 361 they will result in performance degradation. 363 ISPs should filter the routing announcements they hear, for example 364 to ignore routes to addresses allocated for private Internets, to 365 avoid bogus routes and to implement "BGP Route Flap Dampening" 366 [RFC2439] and aggregation policy. 368 ISPs should implement techniques that reduce the risk of putting 369 excessive load on routing in other parts of the network. These 370 include 'nailed up' routes, aggressive aggregation and route 371 dampening, all of which lower the impact on others when your internal 372 routing changes in a way that isn't relevant to them. 374 4.6 Directed Broadcast 376 The IP protocol allows for directed broadcast, the sending of a 377 packet across the network to be broadcast on to a specific subnet. 378 Very few practical uses for this feature exist, but several different 379 security attacks (primarily Denial of Service attacks making use of 380 the packet multiplication effect of the broadcast) use it. 381 Therefore, routers connected to a broadcast medium MUST NOT be 382 configured to allow directed broadcasts onto that medium [RFC2644]. 384 5 Systems Infrastructure 386 The way an ISP manages their systems is crucial to the security and 387 reliability of their network. A breach of their systems may 388 minimally lead to degraded performance or functionality, but could 389 lead to loss of data or the risk of traffic being eavesdropped (thus 390 leading to 'man-in-the-middle' attacks). 392 It's widely accepted that it's easier to build secure systems if 393 different services (such as mail, news and web-hosting) are kept on 394 separate systems. 396 5.1 System Management 398 All systems that perform critical ISP functions such as mail, news 399 and web-hosting, should be restricted such that access to them is 400 only available to the administrators of those services. That access 401 should be granted only following strong authentication, and should 402 take place over an encrypted link. Only the ports on which those 403 services listen should be reachable from outside of the ISP's systems 404 networks. 406 ISPs should stay up to date for more secure methods of providing 407 services as they become available (e.g., IMAP/POP AUTHorize Extension 408 for Simple Challenge/Response, [RFC2195]). 410 5.2 No Systems on Transit Networks 412 Systems should not be attached to transit network segments. 414 5.3 Open Mail Relay 416 ISPs should take active steps to prevent their mail infrastructure 417 from being used by 'spammers' to inject Unsolicited Bulk E-mail (UBE) 418 while hiding the sender's identity [RFC2505]. While not all 419 preventive steps are appropriate for every site, the most effective 420 site-appropriate methods should be used. 422 ISPs should also strongly encourage their customers to take the 423 necessary steps to prevent this activity on their own systems. 425 5.4 Message Submission 427 Message submissions should be authenticated using the AUTH SMTP 428 service extension as described in the "SMTP Service Extension for 429 Authentication" [RFC2554]. 431 SMTP AUTH is preferred over IP address-based submission restrictions 432 in that it gives the ISP's customers the flexibility of being able to 433 submit mail even when not connected through the ISP's network (for 434 example, while at work), is more resistant to spoofing, and can be 435 upgraded to newer authentication mechanisms as they become available. 437 In addition, to facilitate the enforcement of security policy, it is 438 strongly recommended that messages be submitted using the MAIL SUBMIT 439 port (587) as discussed in "Message Submission" [RFC2476], rather 440 than through the SMTP port (25). In this way the SMTP port (25) can 441 be restricted to local delivery only. 443 The reason for this is to be able to differentiate between inbound 444 local delivery and relay (i.e., allow customers to send email via the 445 ISP's SMTP service to arbitrary receivers on the Internet). Non- 446 authenticated SMTP should only be allowed for local delivery. 448 As more and more mail clients support both SMTP AUTH and the message 449 submission port (either explicitly or by configuring the SMTP port), 450 ISPs may find it useful to require that customers submit messages 451 using both the submission port and SMTP AUTH; permitting only inbound 452 mail on port 25. 454 These measures (SMTP AUTH and the submission port) not only protect 455 the ISP from serving as a UBE injection point via third-party relay, 456 but also help in tracking accountability for message submission in 457 the case where a customer sends UBE. 459 6 References 461 [CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal 462 Connections", ftp://info.cert.org/pub/cert_advisories/ 464 [CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks", 465 ftp://info.cert.org/pub/cert_advisories/ 467 [DPR1998] The UK "Data Protection Act 1998 (c. 29)", 468 http://www.hmso.gov.uk/acts/acts1998/19980029.htm 470 [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., 471 Karrenberg, D., Terpstra, M., and J. Yu, "Representation of IP 472 Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, 473 March 1995. 475 [RFC1834] Gargano, J., and K. Weiss, "Whois and Network Information 476 Lookup Service", RFC 1834, August 1995. 478 [RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, 479 "Architecture of the WHOIS++ service", RFC 1835, August 1995. 481 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 482 J., and E. Lear, "Address Allocation for Private Internets", BCP 5, 483 RFC 1918, February 1996. 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", RFC 2119, March 1997. 488 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 489 Functions", RFC 2142, May 1997. 491 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 492 AUTHorize Extension for Simple Challenge/Response", RFC 2195, 493 September 1997. 495 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 496 1997. 498 [RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer 499 Security Incident Response", BCP 21, RFC 2350, June 1998. 501 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 502 Signature Option", RFC 2385, August 1998. 504 [RFC2439] Chandra R., Govindan R., and C. Villamizar, "BGP Route 505 Flap Damping", RFC 2439, November 1998. 507 [RFC2476] Gellens R., and J. Klensin, "Message Submission", 508 RFC 2476, December 1998. 510 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 511 BCP 30, RFC 2505, February 1999. 513 [RFC2554] Myers, J., "SMTP Service Extension for Authentication", 514 RFC 2554, March 1999. 516 [RFC2644] 517 Senie, D., "Changing the Default for Directed Broadcasts in 518 Routers", BCP 34, RFC 2644, August 1999. 520 [RFC2827] Ferguson, P., and D. Senie, "Network Ingress Filtering: 521 Defeating Denial of Service Attacks which employ IP Source 522 Address Spoofing", BCP 38, RFC 2827, May 2000. 524 7 Acknowledgements 526 I gratefully acknowledge the constructive comments received from 527 Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall 528 Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, 529 Michael A. Patton, Don Stikvoort and Bill Woodcock. 531 8 Security Considerations 533 This entire document discusses security issues. 535 9 Author's Address 537 Tom Killalea 538 Lisi/n na Bro/n 539 Be/al A/tha na Muice 540 Co. Mhaigh Eo 541 IRELAND 543 Phone: +1 206 266-2196 544 E-Mail: tomk@neart.org 546 10 Full Copyright Statement 548 Copyright (C) The Internet Society (2000). All Rights Reserved. 550 This document and translations of it may be copied and furnished to 551 others, and derivative works that comment on or otherwise explain it 552 or assist in its implmentation may be prepared, copied, published and 553 distributed, in whole or in part, without restriction of any kind, 554 provided that the above copyright notice and this paragraph are 555 included on all such copies and derivative works. However, this 556 document itself may not be modified in any way, such as by removing 557 the copyright notice or references to the Internet Society or other 558 Internet organisations, except as needed for the purpose of 559 developing Internet standards in which case the procedures for 560 copyrights defined in the Internet Standards process must be 561 followed, or as required to translate it into languages other than 562 English. 564 The limited permissions granted above are perpetual and will not be 565 revoked by the Internet Society or its successors or assigns. 567 This document and the information contained herein is provided on an 568 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 569 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 570 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 571 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 572 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 574 This document expires Mar 30, 2001.