Recommended Internet Service Provider Security Services and Procedures
RFC 3013

Document Type RFC - Best Current Practice (November 2000; No errata)
Also known as BCP 46
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3013 (Best Current Practice)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text