idnits 2.17.1 draft-ietf-grip-isp-04.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. ** 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. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC2182' is mentioned on line 768, but not defined == Unused Reference: 'RFC1034' is defined on line 1248, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1251, but no explicit reference was found in the text == Unused Reference: 'RFC1834' is defined on line 1262, but no explicit reference was found in the text == Unused Reference: 'RFC1835' is defined on line 1265, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DPR1984' -- Possible downref: Non-RFC (?) normative reference: ref. 'GAR1997' -- Possible downref: Non-RFC (?) normative reference: ref. 'HUG1995' ** Obsolete normative reference: RFC 977 (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** 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 ** Obsolete normative reference: RFC 2010 (Obsoleted by RFC 2870) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Downref: Normative reference to an Informational RFC: RFC 2196 ** Obsolete normative reference: RFC 2267 (Obsoleted by RFC 2827) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SPE1994' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSH1997' -- Possible downref: Non-RFC (?) normative reference: ref. 'VIX1995' Summary: 17 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Verio Northwest 2 Security Expectations for Internet Service Providers 4 6 Status of this Memo 8 This document is an Internet Draft. Internet Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its Areas, 10 and its Working Groups. Note that other groups may also distribute 11 working documents as Internet Drafts. This Internet Draft is a 12 product of the GRIP Working Group of the IETF. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 19 To learn the current status of any Internet Draft, please check the 20 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 21 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 22 ftp.isi.edu (US West Coast). 24 Copyright Notice 26 Copyright (C) The Internet Society (1998). All Rights Reserved. 28 Abstract 30 The purpose of this document is to express the general Internet 31 community's expectations of Internet Service Providers (ISPs) with 32 respect to security. 34 It is not the intent of this document to define a set of requirements 35 that would be appropriate for all ISPs, but rather to raise awareness 36 among ISPs of the community's expectations, and to provide the 37 community with a framework for discussion of security expectations 38 with current and prospective service providers. 40 Table of Contents 42 1 Introduction 43 1.1 Conventions Used in this Document 45 2 Incident Response 46 2.1 ISPs and Security Incident Response Teams (SIRTs) 47 2.2 Assistance with Inbound Security Incidents 48 2.3 Assistance with Outbound or Transit Security Incidents 49 2.4 Notification of Vulnerabilities and Reporting Incidents 50 2.5 Contact Information 51 2.6 Communication and Authentication 53 3 Appropriate Use Policy 54 3.1 Announcement of Policy 55 3.2 Sanctions 57 4 Protection of the Community 58 4.1 Cooperation 59 4.2 Data Protection 60 4.3 Training 61 4.4 Registry Data Maintenance 63 5 Network Infrastructure 64 5.1 Routers 65 5.2 Switches, Terminal Servers, Modems and other Network Devices 66 5.3 Anonymous telnet and other unlogged connections 67 5.4 The Network Operation Centre (NOC) and Network Management 68 5.5 Physical Security 69 5.6 Routing Infrastructure 70 5.7 Ingress Filtering on Source Address 71 5.8 Egress Filtering on Source Address 72 5.9 Route Filtering 73 5.10 Directed Broadcast 75 6 Systems Infrastructure 76 6.1 Policy 77 6.2 System Management 78 6.3 Backup 79 6.4 Software Distribution 81 7 Domain Name Service (DNS) 82 7.1 DNS Server Management 83 7.2 Authoritative Domain Name Service 84 7.3 Resolution Service 86 8 Email and Mail Services 87 8.1 Mail Server Administration 88 8.2 Secure Mail 89 8.3 Open Mail Relay 90 8.4 Message Submission 91 8.5 POP and IMAP Services 93 9 News Service (NNTP) 94 9.1 News Server Administration 95 9.2 Article Submission 96 9.3 Control Messages 97 9.4 Newsfeed Filters 99 10 Web-related Services 100 10.1 Webhosting Server Administration 101 10.2 Server Side Programs 102 10.3 Data and Databases 103 10.4 Logs and Statistics Reporting 104 10.5 Push and Streaming Services 105 10.6 Commerce 106 10.7 Content Loading and Distributed Authoring 107 10.8 Search Engines and other tools 109 11 References 111 12 Acknowledgements 113 13 Security Considerations 115 14 Author's Address 117 15 Full Copyright Statement 119 1 Introduction 121 The purpose of this document is to express the general Internet 122 community's expectations of Internet Service Providers (ISPs) with 123 respect to security. 125 A goal is that customers could have a framework to facilitate the 126 discussion of security with prospective service providers; 127 regrettably, such a discussion rarely takes place today. 129 Additionally, in informing ISPs of what the community hopes and 130 expects of them, a further goal is to encourage ISPs to become 131 proactive in making security not only a priority, but something to 132 which they point with pride when selling their services. 134 This document is addressed to Internet service purchasing decision- 135 makers (customers) and ISPs. 137 It has been argued that vendors begin to care about security only 138 when prompted by customers. I hope that this document will encourage 139 both parties to more readily express how much they care about 140 security, and that discussion between the community and its ISPs will 141 be increased. 143 1.1 Conventions Used in this Document 145 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 146 and "MAY" in this document are to be interpreted as described in "Key 147 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 149 2 Incident Response 151 A Security Incident Response Team (SIRT) is a team that performs, 152 coordinates, and supports the response to security incidents that 153 involve sites within a defined constituency. The Internet 154 community's expectations of SIRTs are described in a work in progress 155 called "Expectations for Security Incident Response". 157 2.1 ISPs and Security Incident Response Teams (SIRTs) 159 Some ISPs have SIRTs. However it should not be assumed that either 160 the ISP's connectivity customers or a site being attacked by a 161 customer of that ISP can automatically avail of the services of the 162 ISP's SIRT. ISP SIRTs are frequently provided as an added-cost 163 service, with the team defining as their constituency only those who 164 specifically subscribe to (and perhaps pay for) Incident Response 165 services. 167 Thus it's important to determine what incident response and security 168 resources are available to you, and define your incident response 169 escalation chain BEFORE an incident occurs. 171 Customers should find out if their ISP has a SIRT, and if so what the 172 charter, policies and services of that team are. This information is 173 best expressed using the SIRT template as shown in Appendix D of the 174 work in progress called "Expectations for Security Incident 175 Response". If the ISP doesn't have a SIRT they SHOULD describe what 176 role if any they will take in incident response, and SHOULD indicate 177 if there is any SIRT whose constituency would include the customer 178 and to whom incidents could be reported. 180 2.2 Assistance with Inbound Security Incidents 182 When a security incident targeting one of their connectivity 183 customers occurs ISPs SHOULD inform the customer of the attack, and 184 provide assistance to 186 - trace the 'apparent' origin of the attack and attempt to 187 determine the veracity of each step in the path (keeping in 188 mind that the source address may be spoofed). In cases where 189 the source address is spoofed the ISP could trace the point 190 at which the bogusly addressed traffic entered the ISP's 191 network. 193 - obtain contact information for the source of the attack using 194 whois [RFC1834 and RFC1835], the DNS [RFC1034 and RFC1035] or 195 relevant common mailbox names [RFC2142]. 197 - collect and protect evidence of the incident and guard against 198 its destruction or unintentional announcement. 200 If the event continues then, at the customer's request, ISPs may also 201 assist by logging in order to further diagnose the problem, or by 202 filtering certain types of traffic. 204 2.3 Assistance with Outbound or Transit Security Incidents 206 In the case where one of their connectivity customers appears to be 207 the source of a security incident an ISP will frequently be 208 contacted. Once the ISP is satisfied as to the authenticity of the 209 report, they should provide contact information so that the 210 administrators at the source site can be reached by the target site. 212 An ISP may also be contacted to assist with incidents that traverse 213 their network but use bogus source addresses, such as SYN flooding 214 attacks [CA-96.21.tcp_syn_flooding]. Assistance in this case would 215 consist of using network traces on a hop by hop basis to identify the 216 point at which the bogusly addressed traffic entered the ISP's 217 network. In tracing such incidents it's frequently necessary to 218 coordinating with adjacent ISPs to form a complete chain of response 219 teams along the path of the attack. 221 2.4 Notification of Vulnerabilities and Reporting of Incidents 223 ISPs should be proactive in notifying customers of security 224 vulnerabilities in the services they provide. In addition, as new 225 vulnerabilities in systems and software are discovered they should 226 indicate whether their services are threatened by these risks. 228 When security incidents occur that affect components of an ISP's 229 infrastructure the ISP SHOULD promptly report to their customers 231 - who is coordinating response to the incident 233 - the vulnerability 235 - how service was affected 237 - what is being done to respond to the incident 239 - whether customer data may have been compromised 241 - what is being done to eliminate the vulnerability 243 - the expected schedule for response, assuming it can be 244 predicted 246 2.5 Contact Information 248 [RFC2142] states that sites (including ISPs) must maintain a mailbox 249 called SECURITY for network security issues, ABUSE for issues 250 relating to inappropriate public behaviour and NOC for issues 251 relating to network infrastructure. It also lists additional 252 mailboxes that are defined for receiving queries and reports relating 253 to specific services. 255 ISPs should consider using common URLs for expanded details on the 256 above (e.g., http://www.ISP-name-here.net/security/). 258 In addition, ISPs have a duty to make sure that their contact 259 information, in Whois, in the routing registry [RFC1786] or in any 260 other repository, is complete, accurate and reachable. 262 2.6 Communication and Authentication 264 ISPs SHOULD have clear policies and procedures on the sharing of 265 information about a security incident with their customers, with 266 other ISPs or SIRTs, with law enforcement or with the press and 267 general public. 269 ISPs SHOULD also be able to conduct such communication over a secure 270 channel. I recognise that in some jurisdictions secure channels 271 might not be permitted. 273 3 Appropriate Use Policy 275 An Appropriate Use Policy (AUP) SHOULD clearly identify what 276 customers shall and shall not do on the various components of a 277 system or network, including the type of traffic allowed on the 278 networks. The AUP should be as explicit as possible to avoid 279 ambiguity or misunderstanding. 281 Whenever an ISP contracts with a customer to provide connectivity to 282 the Internet that contract SHOULD be governed by an AUP. The AUP 283 should be reviewed each time the contract is up for renewal, and in 284 addition the ISP should proactively notify customers as policies are 285 updated. 287 3.1 Announcement of Policy 289 In addition to communicating their AUP to their customers ISPs should 290 publish their policy in a public place such as their web site so that 291 the community can be aware of what the ISP considers appropriate and 292 can know what action to expect in the event of inappropriate 293 behaviour. 295 3.2 Sanctions 297 An AUP should be clear in stating what sanctions will be enforced in 298 the event of inappropriate behaviour, and ISPs should be forthcoming 299 in announcing to the community when such sanctions are imposed. 301 4 Protection of the Community 303 ISPs play a crucial role in helping to improve the security of the 304 Internet. This and following sections describe a number of issues 305 which, should they be addressed by ISPs in a coordinated and timely 306 way, would have a very positive effect on the security of the 307 network, and would make it much more difficult for the perpetrators 308 to cover their tracks. 310 Later sections cover in some detail issues related to specific 311 services such as ingress filtering and open mail relays. Such issues, 312 if addressed by all the ISPs in a concerted way, could have a very 313 positive effect. 315 4.1 Cooperation 316 This section is about protecting the community. This requires that 317 we as a community work together to that end. It's worth observing 318 that many of the most significant successes in securing the Internet 319 could not have been achieved by anyone acting alone. 321 Cooperation should be put on legal ground. For example prior to 322 entering into peering agreements ISPs should specify the steps they 323 will take to cooperatively track security incidents that involve both 324 peers. 326 4.2 Data Protection 328 Many jurisdictions have the good fortune to have Data Protection 329 Legislation. Where such legislation exists ISPs should consider the 330 personal data they hold and, if necessary, register themselves as 331 Data Controllers and be prepared to make data available according to 332 the terms of the legislation. Given the global nature of the 333 Internet ISPs that are located where no such legislation exists 334 should at least familiarise themselves with their responsibilities by 335 reading a Data Protection Act (e.g., [DPR1984]). 337 4.3 Training 339 It's important that all ISP staff be trained to be security-conscious 340 at all times and to be able to make appropriate use of tools that 341 enhance security. Some issues that they should be particularly aware 342 of include the use of secure channels for confidential information, 343 the risk of attacks that use social engineering, management of data 344 used for authentication, and so on. 346 4.4 Registry Data Maintenance 348 ISPs are commonly responsible for maintaining the data that is stored 349 in global repositories such as the Internet Routing Registry (IRR) 350 and the APNIC, InterNIC and RIPE databases. Updates to this data 351 should only be possible using strong authentication. 353 5 Network Infrastructure 355 ISPs are responsible for managing the network infrastructure of the 356 Internet in such a way that it is 358 - reasonably resistant to known security vulnerabilities 359 - not easily hijacked by attackers for use in subsequent attacks 361 5.1 Routers 363 Routers are an excellent platform from which to launch a security 364 attack, as well as being attractive targets of themselves. 366 Many routers allow an attacker to do dangerous things such as: 368 - sniff transit traffic 370 - manipulate routing tables to redirect traffic 372 - manipulate interface states to disrupt service 374 - create routing flaps which could potentially cause Denial of 375 Service for large parts of the Internet 377 - create packets with spoofed addresses, and with any desired flags 378 set 380 - initiate ICMP packet storms and other Denial of Service attacks 382 - 'black hole' traffic (e.g., by holding a local route to a null or 383 invalid interface, by holding a local route to an invalid 384 next-hop (one which does not itself have a corresponding route, 385 and does not have a default), or worst yet, by using a dynamic 386 routing protocol to advertise availability of a low-cost route 387 and thus actively drawing traffic toward the black hole) 389 - launder connections to third-party destinations, facilitated by 390 the router's lack of logging 392 Such threats are amplified because of the central part in the 393 networking infrastructure that routers occupy, and the large 394 bandwidth frequently available to them. 396 So access to routers SHOULD be based on one-time passwords or better 397 (e.g., Kerberos) and should be as restricted as possible. 399 Sessions SHOULD be encrypted to prevent sessions or data from being 400 stolen and to avoid replay attacks. 402 Routers SHOULD NOT run the 'small services', which are often enabled 403 by default. These may include bootp, chargen, daytime, discard, echo 404 and finger. 406 5.2 Switches, Terminal Servers, Modems and other Network Devices 408 ISPs should be similarly vigilant in their configuration of other 409 network devices. Unfortunately many such devices deployed in the 410 field support only minimal authentication, do authorisation on an 411 all-or-nothing basis and do little or no logging. In the past ISPs 412 have been left with no trail to follow after their switches were 413 reconfigured, their terminal servers were used to launch attacks on 414 third parties or their Uninterruptable Power Supplies were shut down. 416 Where possible access to such devices should be restricted only to 417 legitimate network administrators. 419 Network infrastructure devices frequently don't support extensive 420 internal logging because they have no long-term storage, like hosts' 421 hard drives. Many support syslog or SNMP traps however, or at least 422 a short internal event log or debugging mode which can be captured 423 through the console or a remote login session. 425 Router or switch configurations should always be maintained on a tftp 426 server, so that they can be restored to previous configuration easily 427 and quickly. These backup configurations should obviously be 428 protected so that they cannot be tftp'd by unauthorised parties, or 429 overwritten with new bogus configurations. 431 5.3 Anonymous telnet and other unlogged connections 433 There are many network devices ranging from low-end routers to 434 printers that accept telnet connections without prompting for a 435 password. Obviously such devices, many of which don't maintain audit 436 trails, are very popular among attackers who wish to cover their 437 tracks. 439 If ISPs have such devices on their own network they should restrict 440 access to them. In addition, they should work with their customers 441 to block access to such devices from outside of the customer's 442 network. 444 The use of telnet to manage network elements is strongly discouraged. 446 5.4 The Network Operation Centre (NOC) and Network Management 448 A NOC is a crucial part of an ISP's infrastructure, and should be 449 operated with appropriate regard to security. 451 A NOC frequently has management control over the configuration 452 information of network devices, and should be vigilant in restricting 453 access to that information. Loading of configuration information 454 into network devices is still frequently done using the TFTP protocol 455 [RFC1350], which not only lacks authentication and uses an insecure 456 channel, but calls for great care in configuration at the server end 457 [CA-91:18.Active.Internet.tftp.Attacks]. 459 A NOC will generally perform a network monitoring function by polling 460 (e.g., with ICMP Echo) a set of network devices periodically. In 461 selecting the set of devices to be polled the crucial role of the 462 devices in 5.2 shouldn't be overlooked. 464 Beyond simple polling a NOC will also use a network management 465 protocol such as SNMP to communicate with network devices. Usually 466 this will be used to 'get' the value of various variables, such as 467 the number of packets received on a particular interface. However 468 the protocol can be used to 'set' variables, perhaps with serious 469 results (e.g., the device can be reconfigured). In any case, SNMPv1 470 uses only trivial authentication. Where possible SNMP should be used 471 as a read-only tool to 'get' information from remote devices, and the 472 information gotten should be treated as confidential. 474 A further use of SNMP is in trap reporting, whereby a management 475 station is notified when certain exceptions occur. This information 476 should also be considered confidential, and the NOC should take care 477 that such trap reporting cannot of itself become a Denial of Service 478 attack. 480 5.5 Physical Security 482 The physical security of every installation should be given 483 appropriate consideration. This is particularly so for co-located 484 facilities to which people from different organisations and with 485 different security policies have access. 487 Three types of co-location arrangements are of particular interest: 489 - customers co-locating equipment at an ISP's facility 491 - ISPs co-locating equipment at an external facility with 492 authorised 'remote hands' 494 - ISPs co-locating equipment at an external facility with no 495 authorised physical access 497 The first case is most likely to directly concern the customer. If 498 an ISP has a co-location facility for the hosting of customer-owned 499 equipment many issues arise surrounding customer access to their co- 500 located equipment. 502 Ideally every customer SHOULD have a fully enclosed locking 'cage', 503 akin to a small room with walls and ceiling of heavy wire mesh 504 fencing, containing the racks in which their equipment is mounted. 505 Customers are allowed access to their own cage under escort by one of 506 the ISP's employees, or with keys that grant access specifically to 507 their cage. 509 This assignment of separate cages is expensive in terms of space 510 however, so many ISPs compromise by putting all co-located equipment 511 together in a single machine room, and managing the actions of 512 escorted customers very closely. However this may be insufficient to 513 prevent mishaps such as the accidental disconnection of another 514 customer's equipment. If a single machine room is used then the ISP 515 SHOULD provide separate locking cabinets for each co-location 516 customer in preferance to an 518 A customer SHOULD always be supervised while in the physical presence 519 of any equipment that is not their own, and SHOULD NOT be allowed to 520 touch, photograph, or examine equipment belonging to another 521 customer. 523 Also of concern is layer 2 security of co-located equipment. Customer 524 equipment SHOULD NOT be allowed to share a physical network segment 525 with hosts belonging to anyone else, whether another customer or the 526 ISP themselves. It's common for crackers to exploit weak security or 527 unencrypted remote logins on co-located customer-owned equipment to 528 take control of that equipment and put it into promiscuous listening 529 mode on the local network segment, thereby potentially compromising 530 the privacy and security of any other devices on that segment. 532 When ISPs co-locate network infrastructure components outside of 533 their own premises, such as at peering points or remote POPs, 534 security considerations are extremely important. These locations 535 often play a pivotal role in the network topology, and may be 536 particular targets for attack or vulnerable to accidents. Equipment 537 SHOULD ideally be fully enclosed in locking cabinets or cages to 538 limit physical access. If on-site spares are kept, they should 539 likewise be protected from tampering. Whenever possible, security 540 systems and logging card-swipe locks should be employed. 541 Installations should be inspected periodically for the addition of 542 unauthorised equipment which might be used to 'tap' a connection. As 543 with any other facility, hosts SHOULD NOT be attached to transit 544 segments, and hosts should never have unused physical interfaces 545 attached to network segments. 547 5.6 Routing Infrastructure 549 An ISP's ability to route traffic to the correct destination depends 550 on routing policy as configured in the routing registries [RFC1786]. 551 ISPs SHOULD ensure that the registry information that they maintain 552 can only be updated using strong authentication, and that the 553 authority to make updates is appropriately restricted. 555 Due care should also be taken in determining in whose routing 556 announcements you place greater trust when a choice of routes are 557 available to a destination. In the past bogus announcements have 558 resulted in traffic being 'black holed', or worse, hijacked. BGP 559 authentication SHOULD be used with routing peers. 561 The internal routing protocol that an ISP uses should be chosen with 562 security in mind. It should not be configured with the assumption 563 that route recalculations are rare and expensive as this would leave 564 the way open for a Denial of Service attack. Routing updates should 565 use the highest level of authentication supported by the internal 566 routing protocol. 568 If more specific routes to parts of the ISP's allocated address space 569 are heard from external peers then the ISP needs to be judicious in 570 deciding whether to accept the announcement. Only ISPs who have 571 allowed their CIDR address allocations to become fragmented (by 572 allowing customers to take addressess with them when they change 573 providers) have to face this decision. 575 5.7 Ingress Filtering on Source Address 577 The direction of such filtering is from the edge site (customer) to 578 the Internet. 580 Attackers frequently cover their tracks by using forged source 581 addresses. To divert attention from their own site the source 582 address they choose will generally be from an innocent remote site or 583 indeed from those addresses that are allocated for private Internets 584 [RFC1918]. In addition, forged source addresses are frequently used 585 in spoof-based attacks in order to exploit a trust relationship 586 between hosts. 588 To reduce the incidence of attacks that rely on forged source 589 addresses ISPs should do the following. At the boundary router with 590 each of their customers they SHOULD proactively filter all traffic 591 coming from the customer that has a source address of something other 592 than the addresses that have been assigned to that customer. For a 593 more detailed discussion of this topic see [RFC2267]. 595 There are (rare) circumstances where ingress filtering is not 596 currently possible, for example on large aggregation routers that 597 cannot take the additional load of applying packet filters. In 598 addition, such filtering can cause difficulty for mobile users. 599 Hence, while the use of this technique to prevent spoofing is 600 strongly encouraged, I realise that it is not always feasible. 602 In these rare cases where ingress filtering at the interface between 603 the customer and the ISP is not possible, the customer should be 604 encouraged to implement ingress filtering within their networks. In 605 general filtering should be done as close to the actual hosts as 606 possible. 608 5.8 Egress Filtering on Source Address 610 The direction of such filtering is from the Internet to the edge site 611 (customer). 613 There are many applications in widespread use on the Internet today 614 that grant trust to other hosts based only on ip address (e.g., the 615 Berkeley 'r' commands). These are susceptible to IP spoofing, as 616 described in [CA-95.01.IP.spoofing]. In addition, there are 617 vulnerabilities that depend on the misuse of supposedly locally 618 addresses, such as 'land' as described in [CA-97.28.Teardrop_Land]. 620 To reduce the exposure of their customers to attacks that rely on 621 forged source addresses ISPs should do the following. At the 622 boundary router with each of their customers they SHOULD proactively 623 filter all traffic going to the customer that has a source address of 624 any of the addresses that have been assigned to that customer. 626 The circumstances described in 5.7 in which ingress filtering isn't 627 feasible similarly apply to egress filtering. 629 5.9 Route Filtering 631 Excessive routing updates can be leveraged by an attacker as a base 632 load on which to build a Denial of Service attack. At the very least 633 they will result in performance degradation. 635 ISPs SHOULD filter the routing announcements they hear, for example 636 to ignore routes to addresses allocated for private Internets, to 637 avoid bogus routes and to implement route dampening and aggregation 638 policy. 640 ISPs SHOULD implement techniques that reduce the risk of putting 641 excessive load on routing in other parts of the network. These 642 include 'nailed up' routes, aggressive aggregation and route 643 dampening, all of which lower the impact on others when your internal 644 routing changes in a way that isn't relevant to them. 646 5.10 Directed Broadcast 648 The IP protocol allows for directed broadcast, the sending of a 649 packet across the network to be broadcast on to a specific subnet. 650 Very few practical uses for this feature exist, but several different 651 security attacks (primarily Denial of Service attacks making use of 652 the packet multiplication effect of the broadcast) use it. 653 Therefore, routers connected to a broadcast medium SHOULD NOT be 654 configured to allow directed broadcasts onto that medium. 656 If it is a packet to which the router would respond if received as a 657 unicast, it MAY send a (single) response. If it is not responding 658 (either because it's not appropriate, or has been configured not to) 659 it MAY send an ICMP error. It is also appropriate to silently 660 discard such packets. In any case such packets SHOULD be counted to 661 detect possible attempts to abuse this feature. 663 6 Systems Infrastructure 665 The way an ISP manages their systems is crucial to the security and 666 reliability of their network. A breach of their systems may 667 minimally lead to degraded performance or functionality, but could 668 lead to loss of data or the risk of traffic being eavesdropped (thus 669 leading to 'man-in-the-middle' attacks). 671 In general a 'horses for courses' approach to the provision of 672 systems services should be adopted (i.e., separate systems should be 673 used to deliver each distinct service). Apart from the benefits that 674 accrue in terms of easing systems administration it's widely 675 acknowledged that it's much easier to build secure systems if 676 different services (such as mail, news and web-hosting) are kept on 677 separate systems. 679 6.1 Policy 681 An ISP's policy with regard to privacy, authentication, 682 accountability, application of security patches, availability and 683 violations reporting should all be of interest to their customers, 684 and should be published in a public place such as the ISP's web site. 686 A more detailed discussion of Security Policy can be found in the 687 Site Security Handbook [RFC2196]. 689 6.2 System Management 691 All systems that perform critical ISP functions such as mail, news 692 and web-hosting, should be restricted such that access to them is 693 only available to the administrators of those services. That access 694 should be granted only following strong authentication, and should 695 take place over an encrypted link. Only the ports on which those 696 services listen should be reachable from outside of the ISP's systems 697 networks. 699 If the ISP provides login accounts to customers then the systems that 700 support this service should be isolated from the rest of the ISP's 701 systems networks. 703 If applications such as rdist are used for software distribution and 704 synchronisation then they should be used over a secure channel and 705 with strong authentication, for example over Secure Shell (ssh) 706 [SSH1997]. 708 A system SHOULD NOT be attached to transit segments. 710 If reusable passwords are permitted then users should be educated 711 about how to choose and care for a password, and proactive password 712 checks, password aging and password guessers should be employed. 714 6.3 Backup 716 The importance of backups need not be stressed here. However backups 717 can become the weakest link in a system's security if appropriate 718 care isn't taken of backup media. 720 If backups are done across the network then a secure channel should 721 be used. If volumes are dumped to staging disks during the backup 722 process then access to the images on those staging disks should be as 723 restricted as possible. 725 Backups take on additional significance as audit data following a 726 security incident. 728 Ageing backup media should be destroyed rather than discarded. 730 6.4 Software Distribution 731 ISPs frequently engage in application software distribution. The 732 integrity of the software should be assured by distributing with it a 733 checksum that has been produced with a strong digest function such as 734 SHA-1 [SHA]. 736 7 Domain Name Service (DNS) 738 The DNS is critical to the daily activities of millions of Internet 739 users. Regrettably applications have frequently placed blind trust 740 in the information contained in the DNS, and in the availability of 741 the DNS. However prior to DNSSEC [RFC2065] the DNS protocol lacked 742 security, while widely used implementations of the DNS protocol 743 contain further severe vulnerabilities [VIX1995]. 745 While this section indicates some methods in which the DNS can be 746 made more trustworthy and reliable it cannot be stressed too strongly 747 that name based authentication is inherently insecure. 749 7.1 DNS Server Administration 751 In addition to issues raised in section 6 ISPs will need to address 752 the following issues in administering their DNS servers: 754 - Service Monitoring. 755 The service availability (ability to answer queries) should be 756 monitored. 758 - Clock synchronisation. 759 Servers should synchronise their clocks using the NTP protocol 760 [RFC1305] with authentication. At least two NTP servers should 761 be used. 763 7.2 Authoritative Domain Name Service 765 An Authoritative Server is one that knows the content of a DNS zone 766 from local knowledge, and thus can answer queries about that zone 767 without needing to query other servers. Customers should consider 768 [RFC2182] when choosing secondary DNS servers. 770 ISPs commonly operate as secondary (or slave) servers for their 771 customers, and these servers may provide service for thousands of 772 zones. Regardless of the number of zones, administrators of these 773 servers should be familiar with the Operational Criteria for Root 774 Name Servers [RFC2010], and in particular should follow these 775 guidelines: 777 - Recursion should be disabled for queries. 779 - Zone transfer should be restricted. 780 Apart from the significant load presented by zone transfer 781 with resultant exposure to Denial of Service attacks, ISPs 782 should recognise that some of their customers will consider the 783 contents of their zone files to be private. 785 - Performance Monitoring. 786 Key variables such as queries per second and average latency 787 should be monitored. 789 7.3 Resolution Service 791 ISPs commonly operate DNS resolution service for their customers. In 792 this scenario customers configure their DNS resolver (client) to 793 resolve queries from the ISP's DNS resolution servers. For 794 resolution servers ISPs should follow these guidelines: 796 - Recursion must be enabled for queries. 797 An implication is that ISPs should not use the same servers for 798 resolution service and authoritative DNS service. 800 - Zone transfer should be disallowed. 801 Even though there may be no zones to transfer, allowing zone 802 transfers would expose the servers to Denial of Service attacks. 804 - Performance Monitoring. 805 Key variables such as queries per second and average latency 806 should be monitored. In addition, the hosts generating the 807 highest number of requests should be periodically reported. 809 - Name server software. 810 A name server package should be run that is not vulnerable to 811 server cache poisoning where malicious or misleading data 812 received from a remote name server is cached and is then made 813 available to resolvers that request the cached data. 815 8 Email and Mail Services 817 Email has been the target of some of the most widely reported 818 security attacks, as well as thousands of juvenile hoaxes and pranks. 820 ISPs have a major role in protecting the community from abuse and in 821 educating their customers in appropriate technologies and in 822 appropriate uses of the technology. 824 8.1 Mail Server Administration 826 In configuring mail servers ISPs should follow these guidelines: 828 - Mail software. 829 If possible software that uses a separate receiving/sending agent 830 and a processing agent should be used. A goal is that the 831 receiving/sending agent, which interfaces with remote mail 832 servers, can be run with reduced privilege. 834 - Restrict remote message queue starting. 835 On-demand queue runs (to facilitate customers who receive mail at 836 their own domain and don't have permanent connections) should be 837 restricted, preferably using a strong authentication mechanism. 838 Remote message queue starting is implemented using a variety of 839 mechanisms, one of which is the ETRN SMTP service extension as 840 described in [RFC1985]. 842 - Disable VRFY and EXPN. 843 No more should be revealed about local users or delivery 844 mechanisms than is necessary. 846 - Clock synchronisation. 847 Servers should synchronise their clocks using the NTP protocol 848 [RFC1305] with authentication. At least two NTP servers should 849 be used. 851 - Exception Reporting. 852 Exceptional conditions such as repeated authentication failures, 853 mail loops and abnormal queue length should be trapped and 854 reported. 856 - Restrict Access to mail logs. 857 Mail logs should only be readable by system administrators. 859 8.2 Secure Mail 861 As indicated in 2.6, It's critical that ISPs, and in particular their 862 Security Incident Response personnel, have access to tools that allow 863 them to exchange email securely. 865 8.3 Open Mail Relay 867 An SMTP mail server is said to be running as an 'open' mail relay if 868 it is willing to accept and relay to non-local destinations mail 869 messages that do not originate locally (i.e., neither the originator 870 nor the recipient address is local). Such open relays are frequently 871 used by 'spammers' to inject their Unsolicited Bulk E-mail (UBE) 872 while hiding their identity. There are very limited cases in which 873 an administrator can make a justifiable case for leaving a mail relay 874 on the Internet completely open. 876 The processes for restricting relaying are well documented. It's 877 regrettable that some major software vendors ship their Message 878 Transfer Agents (MTAs) with relaying open by default. 880 While this is an issue for the whole community, ISPs SHOULD be 881 particularly vigilant in disabling open relaying on mail servers that 882 they manage because their high-bandwidth connectivity makes them the 883 preferred injection point for UBE. 885 ISPs SHOULD also strongly encourage their customers to disable open 886 relaying on their mail servers. Sanctions for running an open mail 887 relay should be covered in an ISP's AUP. 889 8.4 Message Submission 891 To facilitate the enforcement of security policy message submission 892 should be done through the MAIL SUBMIT port (587) as proposed in the 893 work in progress called "Message Submission and Relay", rather than 894 through the SMTP port (25). In addition, message submissions should 895 be authenticated using the AUTH SMTP service extension as described 896 in the work in progess called "SMTP Service Extension for 897 Authentication". In this way the SMTP port (25) can be restricted to 898 local delivery only. 900 These two measures not only protect the ISP from serving as a UBE 901 injection point, but also help in tracking accountability for message 902 submission in the case where a customer sends UBE. Furthermore, 903 using the Submit port with SMTP AUTH has additional advantages over 904 IP address-based submission restrictions in that it gives the ISP's 905 customers the flexibility of being able to submit mail even when not 906 connected through the ISP's network (for example, while at work), is 907 more resistant to spoofing, and can be upgraded to newer 908 authentication mechanisms as they become available. 910 The (undocumented) XTND XMIT POP3 extension which allows clients to 911 send mail through the POP3 session rather than using SMTP may also be 912 considered. It also provides a way to support mobile users at sites 913 where open relaying is disabled, and has the benefit of an 914 authenticated connection and a better audit trail. 916 8.5 POP and IMAP Services 918 ISPs who provide POP or IMAP access to mailboxes to their customers 919 SHOULD, at a minimum, support the CRAM-MD5 [RFC2195] or APOP 920 [RFC1939] authentication mechanisms. Support for stronger mechanisms 921 should be considered, as should disabling plaintext (user/password) 922 authentication. 924 9 News Service (NNTP) 926 As in the case of SMTP, the NNTP protocol [RFC977] used by News 927 suffers from a lack of authentication, and so it's trivial to forge 928 news postings. Forgeries can bypass the moderation process, cancel 929 legitimate articles and create havoc for sites that maintain an 930 active file. 932 The lack of encryption in the protocol and the manner in which many 933 news systems are maintained lead to privacy issues in that it's easy 934 for others to detect what newsgroups and articles you are reading. 936 9.1 News Server Administration 938 In configuring news servers ISPs should follow these guidelines: 940 - News software. 941 A news software package should be run that is not vulnerable to 942 maliciously formed news control messages or buffer overflows. 944 - Disable other services. 945 Given news' propensity to consume all available disk space and 946 CPU cycles it's particularly important that news systems do not 947 perform other services. 949 - Do not interpret batches. 950 If incoming batches of articles are supported they should not 951 be fed to a command interpreter. 953 - Restrict Access to news logs. 954 News logs should only be readable by system administrators. 956 - Authenticate approved headers. 957 If possible support for cryptographic authentication of approved 958 messages should be supported, particularly in the case of group 959 control messages. 961 9.2 Article Submission 963 As many of the issues relating to open mail relays (8.3) apply to 964 news, ISPs should restrict article submission only to approved 965 customers. Further, the networks from which posting is allowed and 966 the newsgroups to which posting is allowed should be as restricted as 967 possible. 969 9.3 Control Messages 971 Control messages attempt to cause the news server to take action 972 beyond filing and passing on the article. Certain control messages, 973 because of the ease with which they can be forged, should be handled 974 with care. While it is up to the ISP to decide whether to take 975 action they must at least propagate control messages even if they do 976 not understand them. 978 - 'whogets', 'sendsys', 'version' should be ignored by ISPs. 980 - While 'cancel' messages must be acted on and propagated their 981 sheer volume can sometimes swamp service, and the fact that much 982 of that volume is computer-generated is worrying. 984 - Systems that require the maintenance of an active file should 985 exercise extreme caution in choosing which if any group control 986 messages (checkgroups, newgroup, rmgroup) should result in 987 action being taken. 989 9.4 Newsfeed Filters 991 The most obvious form of security problem with news is 'leakage' of 992 articles which are intended to have only restricted circulation. The 993 flooding algorithm is extremely good at finding any path by which 994 articles can leave a subnet with supposedly restrictive boundaries. 995 Substantial administrative effort is required to ensure that local 996 newsgroups remain local [SPE1994]. 998 ISPs who provide customers with the ability to remotely manipulate 999 their inbound filters should use strong authentication for this 1000 service. 1002 ISPs should not propagate articles that are excessively crossposted. 1003 10 or more cross-postings is widely agreed to be excessive. 1005 ISPs should impose an upper limit on the article size that they will 1006 propagate. 1008 10 Web-hosting Services 1010 Sites frequently choose to out-source the operation and 1011 administration of their site to an ISP, and security is often a 1012 prominent motivator for doing so. The hosting of such sites and 1013 provision of related services is the subject of this section. 1014 Further information on the topic can be found in [GAR1997] and 1015 [HUG1995]. 1017 10.1 Webhosting Server Administration 1019 In addition to issues raised in section 6 ISPs will need to address 1020 the following issues in administering their web-hosting servers: 1022 - Service Monitoring. 1023 The service availability (ability to answer HTTP requests) should 1024 be monitored. 1026 - Clock synchronisation. 1027 Servers should synchronise their clocks using the NTP protocol 1028 [RFC1305] with authentication. At least two NTP servers should 1029 be used. 1031 - DNS. 1032 DNS lookups should not be performed on web clients when they 1033 connect because they expose the web servers to DNS-based Denial 1034 of Service attacks, and they adversely affect performance. 1036 - DocumentRoot. 1037 Everything below this directory should be subject to the 1038 strictest scrutiny. 1040 - UserDir. 1041 Users other than administrators should not be permitted on the 1042 server. If users have accounts then the 'UserDir' directive, if 1043 permitted, SHOULD NOT access their private accounts. In 1044 particular, scripts SHOULD NOT be permitted to be run from their 1045 accounts. 1047 - Process User and Group. 1048 The web daemon SHOULD be run as a user and group that is set up 1049 specifically for that purpose, and that user/group should have 1050 minimal privilege. This user should be different from the 1051 maintainers of the web content. 1053 - Partitioning of Virtual Sites. 1054 A single server that hosts multiple sites (virtual domains) 1055 SHOULD be set up such that all data, programs and logs for the 1056 different sites are partitioned from each other such that no 1057 access to the configuration or data of each other's sites is 1058 possible. In addition, it should not be possible to access the 1059 data or programs of one customer's site using a URL that has 1060 the name of another customer's site in it's host part. 1062 - Access Control. 1063 Restricted access to certain parts of a site should be 1064 facilitated using a strong authentication mechanism such as a 1065 certificate or a one-time password device. An alternative is 1066 to use well-chosen passwords in conjunction with SSL which at 1067 least avoids passwords being passed across the network in 1068 plaintext. 1070 - Security Patches. 1071 The stakes in running a web server are particularly high, so 1072 administrators should be particularly vigilant in applying 1073 security patches as they are released. 1075 10.2 Server Side Programs 1077 Server side programs such as those that use the Common Gateway 1078 Interface (CGI) are crucial to the flexibility of the web as a 1079 communications medium. However that flexibility introduces security 1080 risks and a weak program threatens all of the virtual hosts on the 1081 server that runs it. An ISP's policy with regard to what programs it 1082 will allow is a good indicator of security policy in general. 1084 ISPs should follow these guidelines on server side programs and CGIs: 1086 - Security Policy. 1087 ISPs should give their customers clear guidelines about how to 1088 write secure programs for their hosting environment, and give 1089 specific indications about what programming practices will result 1090 in a program being rejected. 1092 - Program Installation. 1093 Customers should never be allowed to install their own programs. 1094 All programs and scripts should be submitted to the ISP first to 1095 be checked for conformance with security policy. The programs 1096 SHOULD be installed such that only the server administrators have 1097 permission to modify them. 1099 - Process User and Group. 1100 Programs SHOULD be run as a user and group that is set up 1101 specifically for that purpose, and that user/group should have 1102 minimal privilege (many sites use 'nobody'). 1104 - Display by Browsers. 1105 Programs SHOULD never be allowed to be viewed by browsers. One 1106 implication of that is that they SHOULD NOT be put under the 1107 DocumentRoot. 1109 - Partitioning of Virtual Sites. 1110 Programs SHOULD NOT be accessible through the site of another 1111 customer on the same server, or to the webmaster of that other 1112 customer. 1114 - User Input. 1115 Expressions SHOULD NOT be evaluated based on user input except 1116 when used with the equivalent of Perl's tainting features. 1118 - Processing Limit. 1119 All programs SHOULD have a limit set on real and CPU time, and on 1120 the amount of disk space that they can consume. 1122 - Paths. 1123 All paths SHOULD be full or starting at DocumentRoot, and the 1124 PATH variable should be set by the server administrator. 1126 10.3 Data and Databases 1128 Data that is written by server-side programs such as CGI scripts 1129 should be considered confidential and to prevent them being read by 1130 browsers their permission should be such that they're not readable by 1131 the web daemon process. 1133 If access to a back-end database is provided then programs that 1134 facilitate such access should have the least privilege that is 1135 absolutely necessary. 1137 Data that relates to state management (cookies) that is stored on the 1138 server should be considered confidential and should not be accessible 1139 from browsers. 1141 10.4 Logs and Statistics Reporting 1143 The logs generated by the web daemon process can be useful from the 1144 security viewpoint in providing an audit trail of site activity, 1145 however their more common use is for billing and for market and site 1146 analysis. 1148 These logs should be considered highly confidential. 1150 - The only manipulation of them done by the ISP should be that 1151 which is necessary to generate billing information and 1152 periodically rotate them. 1154 - They should be stored outside of DocumentRoot to prevent access 1155 by a browser to them. 1157 - Access to them, whether in raw or summarised format, should be 1158 provided to the customer over a secure channel. 1160 10.5 Push and Streaming Services 1162 ISPs frequently provide their customers with the ability to deliver 1163 content using protocols other than HTTP. Where such add-on services 1164 are provided, both the customer and the ISP should be aware of the 1165 security implications of providing such services. 1167 10.6 Commerce 1169 Many ISPs set up the means whereby their customers can sell goods and 1170 services through their web-hosted sites. Though a server that can 1171 exchange information with a browser over SSL is sometimes described 1172 as a 'secure server' this term can be misleading, and ISPs that host 1173 commerce applications should consider the following: 1175 - Encrypted Transactions. 1176 Transactions should never be stored on the server in unencrypted 1177 form. Public key cryptography should be used such that only the 1178 customer can decrypt the transactions. Even when transactions 1179 are passed directly to a financial institution and to the 1180 customer some part of the transaction will have to be stored by 1181 the ISP for audit trail purposes. 1183 - Transaction Transfer. 1184 If transactions are not processed immediately but instead are 1185 transferred to the customer in batches then that transfer should 1186 occur over a secure channel such as SSL and only after strong 1187 authentication has taken place. Transaction files should be 1188 carefully rotated so that every transaction occurs exactly once. 1190 - Backups. 1191 If transactions are written to backup media then the physical 1192 security of the backup media should be assured. 1194 10.7 Content Loading and Distributed Authoring 1196 The loading of content onto the ISP's server should happen over a 1197 secure channel. 1199 If server support for Distributed Authoring tools is enabled, then 1200 this should be administered with great care to ensure that strong 1201 authentication takes place and that access is given only to the 1202 customer's virtual site, and only to that customer's content 1203 maintainer. 1205 10.8 Search Engines and other tools 1207 ISPs frequently install tools such as search engines, link checkers 1208 and so on for use by their customers. Many such tools create a very 1209 great processing overhead when run and so running them on-demand 1210 should not be allowed to avoid Denial of Service attacks. 1212 Search engines should be configured so that their searches are 1213 restricted to those parts of a site that are available to all. 1215 The output of link checkers should be considered confidential, and 1216 should only be available to the content maintainer of the customer's 1217 site. 1219 11 References 1221 [CA-91:18.Active.Internet.tftp.Attacks] "Active Internet tftp 1222 Attacks", ftp://info.cert.org/pub/cert_advisories/ 1224 [CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal 1225 Connections", ftp://info.cert.org/pub/cert_advisories/ 1227 [CA-96.21.tcp_syn_flooding] "TCP SYN Flooding and IP Spoofing 1228 Attacks", ftp://info.cert.org/pub/cert_advisories/ 1230 [CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks", 1231 ftp://info.cert.org/pub/cert_advisories/ 1233 [DPR1984] The UK "Data Protection Act 1984 (c. 35)", 1234 http://www.hmso.gov.uk/acts/acts1984/1984035.htm 1236 [GAR1997] Garfinkel, S., "Web Security and Commerce", 1237 O'Reilly and Associates, Sebastopol, CA, 1997. 1239 [HUG1995] Hughes Jr., L., "Actually Useful Internet Security 1240 Techniques", New Riders Publishing, Indianapolis, IN, 1995. 1242 [RFC977] Kantor, B and P. Lapsley, "Network News Transfer Protocol", 1243 RFC 977, February 1986. 1245 [RFC1350] Sollins, K. R., "The TFTP Protocol (revision 2)", STD 33, 1246 RFC 1350, July 1992. 1248 [RFC1034] Mockapetris, P. V., "Domain names - concepts and 1249 facilities", STD 13, RFC 1034, November 1987. 1251 [RFC1035] Mockapetris, P. V., "Domain names - implementation and 1252 specification", STD 13, RFC 1035, November 1987. 1254 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1255 Specification, Implementation", RFC 1305, March 1992. 1257 [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., 1258 Karrenberg, D., Terpstra, M., and J. Yu, "Representation of IP 1259 Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, 1260 March 1995. 1262 [RFC1834] Gargano, J., and K. Weiss, "Whois and Network Information 1263 Lookup Service", RFC 1834, August 1995. 1265 [RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, 1266 "Architecture of the WHOIS++ service", RFC 1835, August 1995. 1268 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 1269 J., and E. Lear, "Address Allocation for Private Internets", BCP 5, 1270 RFC 1918, February 1996. 1272 [RFC1939] Myers, J., and M. Rose, "Post Office Protocol - Version 1273 3", RFC 1939, May 1996. 1275 [RFC1985] De Winter, J. "SMTP Service Extension for Remote Message 1276 Queue Starting", RFC 1985, August 1996. 1278 [RFC2010] Manning, B., and P. Vixie, "Operational Criteria for Root 1279 Name Servers", RFC 2010, October 1996. 1281 [RFC2065] Eastlake 3rd, D., and C. Kaufman, "Domain Name System 1282 Security Extensions", RFC 2065, January 1997. 1284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1285 Requirement Levels", RFC 2119, March 1997. 1287 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 1288 Functions", RFC 2142, May 1997. 1290 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 1291 AUTHorize Extension for Simple Challenge/Response", RFC 2195, 1292 September 1997. 1294 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 1295 1997. 1297 [RFC2267] Ferguson, P., and D. Senie, "Network Ingress Filtering: 1298 Defeating Denial of Service Attacks which employ IP Source 1299 Address Spoofing", RFC 2267, January 1998. 1301 [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 1303 [SPE1994] Spencer, H., "News Article Format and Transmission", 1304 ftp://ftp.zoo.toronto.edu/pub/news.txt.Z 1306 [SSH1997] SSH (secure Shell) Remote Login Program, 1307 http://www.cs.hut.fi/ssh/ 1309 [VIX1995] Vixie, P., "DNS and BIND Security Issues", 1310 ftp://ftp.vix.com/pri/vixie/bindsec.psf, 1995. 1312 12 Acknowledgements 1314 I gratefully acknowledge the constructive comments received from 1315 Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall 1316 Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, 1317 Michael A. Patton, Don Stikvoort and Bill Woodcock. 1319 13 Security Considerations 1321 This entire document discusses security issues. 1323 14 Author's Address 1325 Tom Killalea 1326 Verio Northwest 1327 15400 SE 30th Pl., Ste. 202 1328 Bellevue, WA 98007-6546 1329 USA 1331 Phone: +1 425 649-7417 1332 E-Mail: tomk@nw.verio.net 1334 15 Full Copyright Statement 1336 Copyright (C) The Internet Society (1998). All Rights Reserved. 1338 This document and translations of it may be copied and furnished to 1339 others, and derivative works that comment on or otherwise explain it 1340 or assist in its implmentation may be prepared, copied, published and 1341 distributed, in whole or in part, without restriction of any kind, 1342 provided that the above copyright notice and this paragraph are 1343 included on all such copies and derivative works. However, this 1344 document itself may not be modified in any way, such as by removing 1345 the copyright notice or references to the Internet Society or other 1346 Internet organisations, except as needed for the purpose of 1347 developing Internet standards in which case the procedures for 1348 copyrights defined in the Internet Standards process must be 1349 followed, or as required to translate it into languages other than 1350 English. 1352 The limited permissions granted above are perpetual and will not be 1353 revoked by the Internet Society or its successors or assigns. 1355 This document and the information contained herein is provided on an 1356 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1357 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1358 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1359 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1360 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1362 This document expires Sep 15, 1998.