idnits 2.17.1 draft-ietf-grip-isp-expectations-01.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 551 lines 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 (June 1999) is 9080 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 465, but no explicit reference was found in the text == Unused Reference: 'RFC1835' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC2196' is defined on line 485, 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 (~~), 7 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.ie 3 Valid for six months June 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 47 1 Introduction 48 1.1 Conventions Used in this Document 50 2 Communication 51 2.1 Contact Information 52 2.2 Information Sharing 53 2.3 Secure Channels 54 2.4 Notification of Vulnerabilities and Reporting Incidents 55 2.5 ISPs and Computer Security Incident Response Teams (CSIRTs) 57 3 Appropriate Use Policy 58 3.1 Announcement of Policy 59 3.2 Sanctions 60 3.3 Data Protection 62 4 Network Infrastructure 63 4.1 Registry Data Maintenance 64 4.2 Routing Infrastructure 65 4.3 Ingress Filtering on Source Address 66 4.4 Egress Filtering on Source Address 67 4.5 Route Filtering 68 4.6 Directed Broadcast 70 5 Systems Infrastructure 71 5.1 System Management 72 5.2 No Systems on Transit Networks 73 5.3 Open Mail Relay 74 5.4 Message Submission 76 6 References 78 7 Acknowledgements 80 8 Security Considerations 82 9 Author's Address 84 10 Full Copyright Statement 86 1 Introduction 88 The purpose of this document is to express the general Internet 89 community's expectations of Internet Service Providers (ISPs) with 90 respect to security. This document is addressed to ISPs. 92 By informing ISPs of what the 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 1.1 Conventions Used in this Document 102 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 103 and "MAY" in this document are to be interpreted as described in "Key 104 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 106 2 Communication 108 The community's most significant security-related expectations of 109 ISPs relate to the availability of communication channels for dealing 110 with security incidents. 112 2.1 Contact Information 114 ISPs SHOULD adhere to [RFC2142], which defines the mailbox SECURITY 115 for network security issues, ABUSE for issues relating to 116 inappropriate public behaviour and NOC for issues relating to network 117 infrastructure. It also lists additional mailboxes that are defined 118 for receiving queries and reports relating to specific services. 120 ISPs may consider using common URLs for expanded details on the above 121 (e.g., http://www.ISP-name-here.net/security/). 123 In addition, ISPs have a duty to make sure that their contact 124 information, in Whois, in the routing registry [RFC1786] or in any 125 other repository, is complete, accurate and reachable. 127 2.2 Information Sharing 129 ISPs SHOULD have clear policies and procedures on the sharing of 130 information about a security incident with their customers, with 131 other ISPs or CSIRTs, with law enforcement or with the press and 132 general public. 134 2.3 Secure Channels 136 ISPs SHOULD be able to conduct such communication over a secure 137 channel. Note, however, that in some jurisdictions secure channels 138 might not be permitted. 140 2.4 Notification of Vulnerabilities and Reporting of Incidents 142 ISPs SHOULD be proactive in notifying customers of security 143 vulnerabilities in the services they provide. In addition, as new 144 vulnerabilities in systems and software are discovered they should 145 indicate whether their services are threatened by these risks. 147 When security incidents occur that affect components of an ISP's 148 infrastructure the ISP should promptly report to their customers 150 - who is coordinating response to the incident 152 - the vulnerability 154 - how service was affected 156 - what is being done to respond to the incident 158 - whether customer data may have been compromised 160 - what is being done to eliminate the vulnerability 162 - the expected schedule for response, assuming it can be 163 predicted 165 2.5 Incident Response and Computer Security Incident Response Teams 166 (CSIRTs) 168 A Computer Security Incident Response Team (CSIRT) is a team that 169 performs, coordinates, and supports the response to security 170 incidents that involve sites within a defined constituency. The 171 Internet community's expectations of CSIRTs are described in 172 "Expectations for Computer Security Incident Response" [RFC2350]. 174 Whether or not an ISP has a CSIRT, they should have a well-advertised 175 way to receive and handle reported incidents from their customers. 176 In addition, they should clearly document their capability to respond 177 to reported incidents, and should indicate if there is any CSIRT 178 whose constituency would include the customer and to whom incidents 179 could be reported. 181 Some ISPs have CSIRTs. However it should not be assumed that either 182 the ISP's connectivity customers or a site being attacked by a 183 customer of that ISP can automatically avail themselves of the 184 services of the ISP's CSIRT. ISP CSIRTs are frequently provided as 185 an added-cost service, with the team defining as their constituency 186 only those who specifically subscribe to (and perhaps pay for) 187 Incident Response services. 189 Thus it's important for ISPs to publish what incident response and 190 security resources they make available to customers, so that the 191 customers can define their incident response escalation chain BEFORE 192 an incident occurs. 194 Customers should find out whether their ISP has a CSIRT, and if so 195 what the charter, policies and services of that team are. This 196 information is best expressed using the CSIRT template as shown in 197 Appendix D of "Expectations for Computer Security Incident Response" 198 [RFC2350]. 200 3 Appropriate Use Policy 202 Every ISP SHOULD have an Appropriate Use Policy (AUP). 204 Whenever an ISP contracts with a customer to provide connectivity to 205 the Internet that contract should be governed by an AUP. The AUP 206 should be reviewed each time the contract is up for renewal, and in 207 addition the ISP should proactively notify customers as policies are 208 updated. 210 An AUP should clearly identify what customers shall and shall not do 211 on the various components of a system or network, including the type 212 of traffic allowed on the networks. The AUP should be as explicit as 213 possible to avoid ambiguity or misunderstanding. For example, an AUP 214 might prohibit IP spoofing. 216 3.1 Announcement of Policy 218 In addition to communicating their AUP to their customers ISPs should 219 publish their policy in a public place such as their web site so that 220 the community can be aware of what the ISP considers appropriate and 221 can know what action to expect in the event of inappropriate 222 behaviour. 224 3.2 Sanctions 226 An AUP should be clear in stating what sanctions will be enforced in 227 the event of inappropriate behaviour, and ISPs should be forthcoming 228 in announcing to the community when such sanctions are imposed. 230 3.3 Data Protection 232 Many jurisdictions have Data Protection Legislation. Where such 233 legislation applies, ISPs should consider the personal data they hold 234 and, if necessary, register themselves as Data Controllers and be 235 prepared to only use the data in accordance with the terms of the 236 legislation. Given the global nature of the Internet ISPs that are 237 located where no such legislation exists should at least familiarise 238 themselves with the idea of Data Protection by reading a typical Data 239 Protection Act (e.g., [DPR1998]). 241 4 Network Infrastructure 243 ISPs are responsible for managing the network infrastructure of the 244 Internet in such a way that it is 246 - reasonably resistant to known security vulnerabilities 248 - not easily hijacked by attackers for use in subsequent attacks 250 4.1 Registry Data Maintenance 252 ISPs are commonly responsible for maintaining the data that is stored 253 in global repositories such as the Internet Routing Registry (IRR) 254 and the APNIC, InterNIC and RIPE databases. Updates to this data 255 should only be possible using strong authentication. 257 ISPs should 'SWIP' (Shared WhoIs Project) the address space that they 258 assign to their customers so that there is more specific contact 259 information for the delegated space. 261 4.2 Routing Infrastructure 263 An ISP's ability to route traffic to the correct destination depends 264 on routing policy as configured in the routing registries [RFC1786]. 265 ISPs should ensure that the registry information that they maintain 266 can only be updated using strong authentication, and that the 267 authority to make updates is appropriately restricted. 269 Due care should also be taken in determining in whose routing 270 announcements you place greater trust when a choice of routes are 271 available to a destination. In the past bogus announcements have 272 resulted in traffic being 'black holed', or worse, hijacked. BGP 273 authentication should be used with routing peers. 275 4.3 Ingress Filtering on Source Address 277 The direction of such filtering is from the edge site (customer) to 278 the Internet. 280 Attackers frequently cover their tracks by using forged source 281 addresses. To divert attention from their own site the source 282 address they choose will generally be from an innocent remote site or 283 indeed from those addresses that are allocated for private Internets 284 [RFC1918]. In addition, forged source addresses are frequently used 285 in spoof-based attacks in order to exploit a trust relationship 286 between hosts. 288 To reduce the incidence of attacks that rely on forged source 289 addresses ISPs should do the following. At the boundary router with 290 each of their customers they should proactively filter all traffic 291 coming from the customer that has a source address of something other 292 than the addresses that have been assigned to that customer. For a 293 more detailed discussion of this topic see [RFC2267]. 295 There are (rare) circumstances where ingress filtering is not 296 currently possible, for example on large aggregation routers that 297 cannot take the additional load of applying packet filters. In 298 addition, such filtering can cause difficulty for mobile users. 299 Hence, while the use of this technique to prevent spoofing is 300 strongly encouraged, it may not always be feasible. 302 In these rare cases where ingress filtering at the interface between 303 the customer and the ISP is not possible, the customer should be 304 encouraged to implement ingress filtering within their networks. In 305 general filtering should be done as close to the actual hosts as 306 possible. 308 4.4 Egress Filtering on Source Address 310 The direction of such filtering is from the Internet to the edge site 311 (customer). 313 There are many applications in widespread use on the Internet today 314 that grant trust to other hosts based only on ip address (e.g., the 315 Berkeley 'r' commands). These are susceptible to IP spoofing, as 316 described in [CA-95.01.IP.spoofing]. In addition, there are 317 vulnerabilities that depend on the misuse of supposedly local 318 addresses, such as 'land' as described in [CA-97.28.Teardrop_Land]. 320 To reduce the exposure of their customers to attacks that rely on 321 forged source addresses ISPs should do the following. At the 322 boundary router with each of their customers they should proactively 323 filter all traffic going to the customer that has a source address of 324 any of the addresses that have been assigned to that customer. 326 The circumstances described in 5.7 in which ingress filtering isn't 327 feasible apply similarly to egress filtering. 329 4.5 Route Filtering 331 Excessive routing updates can be leveraged by an attacker as a base 332 load on which to build a Denial of Service attack. At the very least 333 they will result in performance degradation. 335 ISPs should filter the routing announcements they hear, for example 336 to ignore routes to addresses allocated for private Internets, to 337 avoid bogus routes and to implement "BGP Route Flap Dampening" 338 [RFC2439] and aggregation policy. 340 ISPs should implement techniques that reduce the risk of putting 341 excessive load on routing in other parts of the network. These 342 include 'nailed up' routes, aggressive aggregation and route 343 dampening, all of which lower the impact on others when your internal 344 routing changes in a way that isn't relevant to them. 346 4.6 Directed Broadcast 348 The IP protocol allows for directed broadcast, the sending of a 349 packet across the network to be broadcast on to a specific subnet. 350 Very few practical uses for this feature exist, but several different 351 security attacks (primarily Denial of Service attacks making use of 352 the packet multiplication effect of the broadcast) use it. 353 Therefore, routers connected to a broadcast medium SHOULD NOT be 354 configured to allow directed broadcasts onto that medium. 356 If it is a packet to which the router would respond if received as a 357 unicast, it MAY send a (single) response. If it is not responding 358 (either because it's not appropriate, or because it's been configured 359 not to) it MAY send an ICMP error. It is also appropriate to 360 silently discard such packets. In any case such packets should be 361 counted to detect possible attempts to abuse this feature. 363 See the work in progress [DRAFT-SENIE] for further discussion of this 364 issue. 366 5 Systems Infrastructure 368 The way an ISP manages their systems is crucial to the security and 369 reliability of their network. A breach of their systems may 370 minimally lead to degraded performance or functionality, but could 371 lead to loss of data or the risk of traffic being eavesdropped (thus 372 leading to 'man-in-the-middle' attacks). 374 It's widely accepted that it's easier to build secure systems if 375 different services (such as mail, news and web-hosting) are kept on 376 separate systems. 378 5.1 System Management 380 All systems that perform critical ISP functions such as mail, news 381 and web-hosting, should be restricted such that access to them is 382 only available to the administrators of those services. That access 383 should be granted only following strong authentication, and should 384 take place over an encrypted link. Only the ports on which those 385 services listen should be reachable from outside of the ISP's systems 386 networks. 388 ISPs should stay up to date for more secure methods of providing 389 services as they become available (e.g., IMAP/POP AUTHorize Extension 390 for Simple Challenge/Response, [RFC2195]). 392 5.2 No Systems on Transit Networks 394 Systems should not be attached to transit network segments. 396 5.3 Open Mail Relay 398 An SMTP mail server is said to be running as an 'open' mail relay if 399 it is willing to accept and relay to non-local destinations mail 400 messages that do not originate locally (i.e., neither the originator 401 nor the recipient address is local). Such open relays are frequently 402 used by 'spammers' to inject their Unsolicited Bulk E-mail (UBE) 403 while hiding their identity. There are only very limited 404 circumstances in which an administrator can make a justifiable case 405 for leaving a mail relay on the Internet completely open. 407 The processes for restricting relaying are well documented. It's 408 regrettable that some major software vendors ship their Message 409 Transfer Agents (MTAs) with relaying open by default. 411 While this is an issue for the whole community, ISPs should be 412 particularly vigilant in disabling open relaying on mail servers that 413 they manage because their high-bandwidth connectivity makes them the 414 preferred injection point for UBE. 416 ISPs should also strongly encourage their customers to disable open 417 relaying on their mail servers. Sanctions for running an open mail 418 relay should be covered in an ISP's AUP. 420 5.4 Message Submission 422 To facilitate the enforcement of security policy message submission 423 should be done through the MAIL SUBMIT port (587) as discussed in 424 "Message Submission" [RFC2476], rather than through the SMTP port 425 (25). In addition, message submissions should be authenticated using 426 the AUTH SMTP service extension as described in the work in progess 427 called "SMTP Service Extension for Authentication". In this way the 428 SMTP port (25) can be restricted to local delivery only. 430 These two measures not only protect the ISP from serving as a UBE 431 injection point, but also help in tracking accountability for message 432 submission in the case where a customer sends UBE. Furthermore, 433 using the Submit port with SMTP AUTH has additional advantages over 434 IP address-based submission restrictions in that it gives the ISP's 435 customers the flexibility of being able to submit mail even when not 436 connected through the ISP's network (for example, while at work), is 437 more resistant to spoofing, and can be upgraded to newer 438 authentication mechanisms as they become available. 440 The (undocumented) XTND XMIT POP3 extension which allows clients to 441 send mail through the POP3 session rather than using SMTP may also be 442 considered. It also provides a way to support mobile users at sites 443 where open relaying is disabled, and has the benefit of an 444 authenticated connection and a better audit trail. 446 6 References 448 [CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal 449 Connections", ftp://info.cert.org/pub/cert_advisories/ 451 [CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks", 452 ftp://info.cert.org/pub/cert_advisories/ 454 [DRAFT-SENIE] 455 draft-senie-directed-broadcast-03.txt 457 [DPR1998] The UK "Data Protection Act 1998 (c. 29)", 458 http://www.hmso.gov.uk/acts/acts1998/19980029.htm 460 [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., 461 Karrenberg, D., Terpstra, M., and J. Yu, "Representation of IP 462 Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, 463 March 1995. 465 [RFC1834] Gargano, J., and K. Weiss, "Whois and Network Information 466 Lookup Service", RFC 1834, August 1995. 468 [RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, 469 "Architecture of the WHOIS++ service", RFC 1835, August 1995. 471 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 472 J., and E. Lear, "Address Allocation for Private Internets", BCP 5, 473 RFC 1918, February 1996. 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", RFC 2119, March 1997. 478 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 479 Functions", RFC 2142, May 1997. 481 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 482 AUTHorize Extension for Simple Challenge/Response", RFC 2195, 483 September 1997. 485 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 486 1997. 488 [RFC2267] Ferguson, P., and D. Senie, "Network Ingress Filtering: 489 Defeating Denial of Service Attacks which employ IP Source 490 Address Spoofing", RFC 2267, January 1998. 492 [RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer 493 Security Incident Response", RFC 2350, June 1998. 495 [RFC2439] Chandra R., Govindan R., and C. Villamizar, "BGP Route 496 Flap Damping", RFC 2439, November 1998. 498 [RFC2476] Gellens R., and J. Klensin, "Message Submission", 499 RFC 2476, December 1998. 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 694-2196 520 E-Mail: tomk@neart.ie 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 December 25, 1999.