rfc3013.txt

RFC 的详细文档！

Network Working Group                                       T. Killalea
Request for Comments: 3013                                    neart.org
BCP: 46                                                   November 2000
Category: Best Current Practice


 Recommended Internet Service Provider Security Services and Procedures

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   The purpose of this document is to express what the engineering
   community as represented by the IETF expects of Internet Service
   Providers (ISPs) with respect to security.

   It is not the intent of this document to define a set of requirements
   that would be appropriate for all ISPs, but rather to raise awareness
   among ISPs of the community's expectations, and to provide the
   community with a framework for discussion of security expectations
   with current and prospective service providers.






















Killalea                 Best Current Practice                  [Page 1]

RFC 3013                Recommended ISP Security           November 2000


Table of Contents

   1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1 Conventions Used in this Document. . . . . . . . . . . . . . 3
   2 Communication. . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1 Contact Information. . . . . . . . . . . . . . . . . . . . . 3
     2.2 Information Sharing. . . . . . . . . . . . . . . . . . . . . 4
     2.3 Secure Channels. . . . . . . . . . . . . . . . . . . . . . . 4
     2.4 Notification of Vulnerabilities and Reporting Incidents. . . 4
     2.5 ISPs and Computer Security Incident Response Teams (CSIRTs). 5
   3 Appropriate Use Policy . . . . . . . . . . . . . . . . . . . . . 5
     3.1 Announcement of Policy . . . . . . . . . . . . . . . . . . . 6
     3.2 Sanctions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.3 Data Protection. . . . . . . . . . . . . . . . . . . . . . . 6
   4 Network Infrastructure . . . . . . . . . . . . . . . . . . . . . 6
     4.1 Registry Data Maintenance. . . . . . . . . . . . . . . . . . 6
     4.2 Routing Infrastructure . . . . . . . . . . . . . . . . . . . 7
     4.3 Ingress Filtering on Source Address. . . . . . . . . . . . . 7
     4.4 Egress Filtering on Source Address . . . . . . . . . . . . . 8
     4.5 Route Filtering. . . . . . . . . . . . . . . . . . . . . . . 8
     4.6 Directed Broadcast . . . . . . . . . . . . . . . . . . . . . 8
   5 Systems Infrastructure . . . . . . . . . . . . . . . . . . . . . 9
     5.1 System Management. . . . . . . . . . . . . . . . . . . . . . 9
     5.2 No Systems on Transit Networks . . . . . . . . . . . . . . . 9
     5.3 Open Mail Relay. . . . . . . . . . . . . . . . . . . . . . . 9
     5.4 Message Submission . . . . . . . . . . . . . . . . . . . . . 9
   6 References . . . . . . . . . . . . . . . . . . . . . . . . . . .10
   7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .12
   8 Security Considerations. . . . . . . . . . . . . . . . . . . . .12
   9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .12
   10 Full Copyright Statement. . . . . . . . . . . . . . . . . . . .13

1 Introduction

   The purpose of this document is to express what the engineering
   community as represented by the IETF expects of Internet Service
   Providers (ISPs) with respect to security.  This document is
   addressed to ISPs.

   By informing ISPs of what this community hopes and expects of them,
   the community hopes to encourage ISPs to become proactive in making
   security not only a priority, but something to which they point with
   pride when selling their services.

   Under no circumstances is it the intention of this document to
   dictate business practices.





Killalea                 Best Current Practice                  [Page 2]

RFC 3013                Recommended ISP Security           November 2000


   In this document we define ISPs to include organisations in the
   business of providing Internet connectivity or other Internet
   services including but not restricted to web hosting services,
   content providers and e-mail services.  We do not include in our
   definition of an ISP organisations providing those services for their
   own purposes.

   This document is offered as a set of recommendations to ISPs
   regarding what security and attack management arrangements should be
   supported, and as advice to users regarding what they should expect
   from a high quality service provider.  It is in no sense normative in
   its own right.  In time it is likely to become dated, and other
   expectations may arise.  However, it does represent a snapshot of the
   recommendations of a set of professionals in the field at a given
   point in the development of the Internet and its technology.

1.1 Conventions Used in this Document

   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
   and "MAY" in this document are to be interpreted as described in "Key
   words for use in RFCs to Indicate Requirement Levels" [RFC2119].

2 Communication

   The community's most significant security-related expectations of
   ISPs relate to the availability of communication channels for dealing
   with security incidents.

2.1 Contact Information

   ISPs SHOULD adhere to [RFC2142], which defines the mailbox SECURITY
   for network security issues, ABUSE for issues relating to
   inappropriate public behaviour and NOC for issues relating to network
   infrastructure.  It also lists additional mailboxes that are defined
   for receiving queries and reports relating to specific services.

   ISPs may consider using common URLs for expanded details on the above
   (e.g., http://www.ISP-name-here.net/security/).

   In addition, ISPs have a duty to make sure that their contact
   information, in Whois, in routing registries [RFC1786] or in any
   other repository, is complete, accurate and reachable.









Killalea                 Best Current Practice                  [Page 3]

RFC 3013                Recommended ISP Security           November 2000


2.2 Information Sharing

   ISPs SHOULD have clear policies and procedures on the sharing of
   information about a security incident with their customers, with
   other ISPs, with Incident Response Teams, with law enforcement or
   with the press and general public.

   ISPs should have processes in place to deal with security incidents
   that traverse the boundaries between them and other ISPs.

2.3 Secure Channels

   ISPs SHOULD be able to conduct such communication over a secure
   channel.  Note, however, that in some jurisdictions secure channels
   might not be permitted.

2.4 Notification of Vulnerabilities and Reporting of Incidents

   ISPs SHOULD be proactive in notifying customers of security
   vulnerabilities in the services they provide.  In addition, as new
   vulnerabilities in systems and software are discovered they should
   indicate whether their services are threatened by these risks.

   When security incidents occur that affect components of an ISP's
   infrastructure the ISP should promptly report to their customers

      -  who is coordinating response to the incident

      -  the vulnerability

      -  how service was affected

      -  what is being done to respond to the incident

      -  whether customer data may have been compromised

      -  what is being done to eliminate the vulnerability

      -  the expected schedule for response, assuming it can be
         predicted

   Many ISPs have established procedures for notifying customers of
   outages and service degradation.  It is reasonable for the ISP to use
   these channels for reporting security-related incidents.  In such
   cases, the customer's security point of contact might not be the
   person notified.  Rather, the normal point of contact will receive
   the report.  Customers should be aware of this and make sure to route
   such notifications appropriately.



Killalea                 Best Current Practice                  [Page 4]

RFC 3013                Recommended ISP Security           November 2000


2.5 Incident Response and Computer Security Incident Response Teams
   (CSIRTs)

   A Computer Security Incident Response Team (CSIRT) is a team that
   performs, coordinates, and supports the response to security
   incidents that involve sites within a defined constituency.  The
   Internet community's expectations of CSIRTs are described in
   "Expectations for Computer Security Incident Response" [RFC2350].

   Whether or not an ISP has a CSIRT, they should have a well-advertised
   way to receive and handle reported incidents from their customers.
   In addition, they should clearly document their capability to respond
   to reported incidents, and should indicate if there is any CSIRT
   whose constituency would include the customer and to whom incidents
   could be reported.

   Some ISPs have CSIRTs.  However it should not be assumed that either
   the ISP's connectivity customers or a site being attacked by a
   customer of that ISP can automatically avail themselves of the
   services of the ISP's CSIRT.  ISP CSIRTs are frequently provided as
   an added-cost service, with the team defining as their constituency
   only those who specifically subscribe to (and perhaps pay for)
   Incident Response services.

   Thus it's important for ISPs to publish what incident response and
   security resources they make available to customers, so that the
   customers can define their incident response escalation chain BEFORE
   an incident occurs.

   Customers should find out whether their ISP has a CSIRT, and if so
   what the charter, policies and services of that team are.  This
   information is best expressed using the CSIRT template as shown in
   Appendix D of "Expectations for Computer Security Incident Response"
   [RFC2350].

3 Appropriate Use Policy

   Every ISP SHOULD have an Appropriate Use Policy (AUP).

   Whenever an ISP contracts with a customer to provide connectivity to
   the Internet that contract should be governed by an AUP.  The AUP
   should be reviewed each time the contract is up for renewal, and in
   addition the ISP should proactively notify customers as policies are
   updated.

   An AUP should clearly identify what customers shall and shall not do
   on the various components of a system or network, including the type




Killalea                 Best Current Practice                  [Page 5]

RFC 3013                Recommended ISP Security           November 2000


   of traffic allowed on the networks.  The AUP should be as explicit as
   possible to avoid ambiguity or misunderstanding.  For example, an AUP
   might prohibit IP spoofing.

3.1 Announcement of Policy

   In addition to communicating their AUP to their customers ISPs should
   publish their policy in a public place such as their web site so that
   the community can be aware of what the ISP considers appropriate and
   can know what action to expect in the event of inappropriate
   behaviour.

3.2 Sanctions

   An AUP should be clear in stating what sanctions will be enforced in
   the event of inappropriate behaviour.

3.3 Data Protection

   Many jurisdictions have Data Protection Legislation.  Where such
   legislation applies, ISPs should consider the personal data they hold
   and, if necessary, register themselves as Data Controllers and be
   prepared to only use the data in accordance with the terms of the
   legislation.  Given the global nature of the Internet ISPs that are
   located where no such legislation exists should at least familiarise
   themselves with the idea of Data Protection by reading a typical Data
   Protection Act (e.g., [DPR1998]).

4 Network Infrastructure

   ISPs are responsible for managing the network infrastructure of the
   Internet in such a way that it is

      -  reasonably resistant to known security vulnerabilities

      -  not easily hijacked by attackers for use in subsequent attacks

4.1 Registry Data Maintenance

   ISPs are commonly responsible for maintaining the data that is stored
   in global repositories such as the Internet Routing Registry (IRR)
   and the APNIC, ARIN and RIPE databases.  Updates to this data should
   only be possible using strong authentication.

   ISPs should publicly register the address space that they assign to
   their customers so that there is more specific contact information
   for the delegated space.




Killalea                 Best Current Practice                  [Page 6]

RFC 3013                Recommended ISP Security           November 2000


4.2 Routing Infrastructure

   An ISP's ability to route traffic to the correct destination may
   depend on routing policy as configured in routing registries
   [RFC1786].  If so, and if the registry supports it, they should
   ensure that the registry information that they maintain can only be
   updated using strong authentication, and that the authority to make
   updates is appropriately restricted.

   Due care should also be taken in determining in whose routing
   announcements you place greater trust when a choice of routes are
   available to a destination.  In the past bogus announcements have
   resulted in traffic being 'black holed', or worse, hijacked.

   BGP authentication [RFC2385] SHOULD be used with routing peers.

4.3 Ingress Filtering on Source Address

   The direction of such filtering is from the edge site (customer) to
   the Internet.

   Attackers frequently cover their tracks by using forged source
   addresses.  To divert attention from their own site the source
   address they choose will generally be from an innocent remote site or