As per Relevance of the word practice, we have this rfc below:
Network Working Group T.
Request for Comments: 3013 neart.
BCP: 46 November 2000
Category: Best Current
Recommended Internet Service Provider Security Services and
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
The purpose of this document is to express what the
community as represented by the IETF expects of Internet
Providers (ISPs) with respect to security
It is not the intent of this document to define a set of
that would be appropriate for all ISPs, but rather to raise
among ISPs of the community's expectations, and to provide
community with a framework for discussion of security
with current and prospective service providers
Killalea Best Current Practice [Page 1]
RFC 3013 Recommended ISP Security November 2000
Table of
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
The purpose of this document is to express what the
community as represented by the IETF expects of Internet
Providers (ISPs) with respect to security. This document
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
security not only a priority, but something to which they point
pride when selling their services
Under no circumstances is it the intention of this document
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
business of providing Internet connectivity or other
services including but not restricted to web hosting services
content providers and e-mail services. We do not include in
definition of an ISP organisations providing those services for
own purposes
This document is offered as a set of recommendations to
regarding what security and attack management arrangements should
supported, and as advice to users regarding what they should
from a high quality service provider. It is in no sense normative
its own right. In time it is likely to become dated, and
expectations may arise. However, it does represent a snapshot of
recommendations of a set of professionals in the field at a
point in the development of the Internet and its technology
1.1 Conventions Used in this
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
and "MAY" in this document are to be interpreted as described in "
words for use in RFCs to Indicate Requirement Levels" [RFC2119].
2
The community's most significant security-related expectations
ISPs relate to the availability of communication channels for
with security incidents
2.1 Contact
ISPs SHOULD adhere to [RFC2142], which defines the mailbox
for network security issues, ABUSE for issues relating
inappropriate public behaviour and NOC for issues relating to
infrastructure. It also lists additional mailboxes that are
for receiving queries and reports relating to specific services
ISPs may consider using common URLs for expanded details on the
(e.g., http://www.ISP-name-here.net/security/).
In addition, ISPs have a duty to make sure that their
information, in Whois, in routing registries [RFC1786] or in
other repository, is complete, accurate and reachable
Killalea Best Current Practice [Page 3]
RFC 3013 Recommended ISP Security November 2000
2.2 Information
ISPs SHOULD have clear policies and procedures on the sharing
information about a security incident with their customers,
other ISPs, with Incident Response Teams, with law enforcement
with the press and general public
ISPs should have processes in place to deal with security
that traverse the boundaries between them and other ISPs
2.3 Secure
ISPs SHOULD be able to conduct such communication over a
channel. Note, however, that in some jurisdictions secure
might not be permitted
2.4 Notification of Vulnerabilities and Reporting of
ISPs SHOULD be proactive in notifying customers of
vulnerabilities in the services they provide. In addition, as
vulnerabilities in systems and software are discovered they
indicate whether their services are threatened by these risks
When security incidents occur that affect components of an ISP'
infrastructure the ISP should promptly report to their
- who is coordinating response to the
- the
- how service was
- what is being done to respond to the
- whether customer data may have been
- what is being done to eliminate the
- the expected schedule for response, assuming it can
Many ISPs have established procedures for notifying customers
outages and service degradation. It is reasonable for the ISP to
these channels for reporting security-related incidents. In
cases, the customer's security point of contact might not be
person notified. Rather, the normal point of contact will
the report. Customers should be aware of this and make sure to
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
(CSIRTs
A Computer Security Incident Response Team (CSIRT) is a team
performs, coordinates, and supports the response to
incidents that involve sites within a defined constituency.
Internet community's expectations of CSIRTs are described
"Expectations for Computer Security Incident Response" [RFC2350].
Whether or not an ISP has a CSIRT, they should have a well-
way to receive and handle reported incidents from their customers
In addition, they should clearly document their capability to
to reported incidents, and should indicate if there is any
whose constituency would include the customer and to whom
could be reported
Some ISPs have CSIRTs. However it should not be assumed that
the ISP's connectivity customers or a site being attacked by
customer of that ISP can automatically avail themselves of
services of the ISP's CSIRT. ISP CSIRTs are frequently provided
an added-cost service, with the team defining as their
only those who specifically subscribe to (and perhaps pay for
Incident Response services
Thus it's important for ISPs to publish what incident response
security resources they make available to customers, so that
customers can define their incident response escalation chain
an incident occurs
Customers should find out whether their ISP has a CSIRT, and if
what the charter, policies and services of that team are.
information is best expressed using the CSIRT template as shown
Appendix D of "Expectations for Computer Security Incident Response
[RFC2350].
3 Appropriate Use
Every ISP SHOULD have an Appropriate Use Policy (AUP).
Whenever an ISP contracts with a customer to provide connectivity
the Internet that contract should be governed by an AUP. The
should be reviewed each time the contract is up for renewal, and
addition the ISP should proactively notify customers as policies
updated
An AUP should clearly identify what customers shall and shall not
on the various components of a system or network, including the
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
possible to avoid ambiguity or misunderstanding. For example, an
might prohibit IP spoofing
3.1 Announcement of
In addition to communicating their AUP to their customers ISPs
publish their policy in a public place such as their web site so
the community can be aware of what the ISP considers appropriate
can know what action to expect in the event of
behaviour
3.2
An AUP should be clear in stating what sanctions will be enforced
the event of inappropriate behaviour
3.3 Data
Many jurisdictions have Data Protection Legislation. Where
legislation applies, ISPs should consider the personal data they
and, if necessary, register themselves as Data Controllers and
prepared to only use the data in accordance with the terms of
legislation. Given the global nature of the Internet ISPs that
located where no such legislation exists should at least
themselves with the idea of Data Protection by reading a typical
Protection Act (e.g., [DPR1998]).
4 Network
ISPs are responsible for managing the network infrastructure of
Internet in such a way that it
- reasonably resistant to known security
- not easily hijacked by attackers for use in subsequent
4.1 Registry Data
ISPs are commonly responsible for maintaining the data that is
in global repositories such as the Internet Routing Registry (IRR
and the APNIC, ARIN and RIPE databases. Updates to this data
only be possible using strong authentication
ISPs should publicly register the address space that they assign
their customers so that there is more specific contact
for the delegated space
Killalea Best Current Practice [Page 6]
RFC 3013 Recommended ISP Security November 2000
4.2 Routing
An ISP's ability to route traffic to the correct destination
depend on routing policy as configured in routing
[RFC1786]. If so, and if the registry supports it, they
ensure that the registry information that they maintain can only
updated using strong authentication, and that the authority to
updates is appropriately restricted
Due care should also be taken in determining in whose
announcements you place greater trust when a choice of routes
available to a destination. In the past bogus announcements
resulted in traffic being 'black holed', or worse, hijacked
BGP authentication [RFC2385] SHOULD be used with routing peers
4.3 Ingress Filtering on Source
The direction of such filtering is from the edge site (customer)
the Internet
Attackers frequently cover their tracks by using forged
addresses. To divert attention from their own site the
address they choose will generally be from an innocent remote site
indeed from those addresses that are allocated for private
[RFC1918]. In addition, forged source addresses are frequently
in spoof-based attacks in order to exploit a trust
between hosts
To reduce the incidence of attacks that rely on forged
addresses ISPs should do the following. At the boundary router
each of their customers they should proactively filter all
coming from the customer that has a source address of something
than the addresses that have been assigned to that customer. For
more detailed discussion of this topic see [RFC2827].
There are (rare) circumstances where ingress filtering is
currently possible, for example on large aggregation routers
cannot take the additional load of applying packet filters.
addition, such filtering can cause difficulty for mobile users
Hence, while the use of this technique to prevent spoofing
strongly encouraged, it may not always be feasible
In these rare cases where ingress filtering at the interface
the customer and the ISP is not possible, the customer should
encouraged to implement ingress filtering within their networks.
general filtering should be done as close to the actual hosts
possible
Killalea Best Current Practice [Page 7]
RFC 3013 Recommended ISP Security November 2000
4.4 Egress Filtering on Source
The direction of such filtering is from the Internet to the edge
(customer).
There are many applications in widespread use on the Internet
that grant trust to other hosts based only on ip address (e.g.,
Berkeley 'r' commands). These are susceptible to IP spoofing,
described in [CA-95.01.IP.spoofing]. In addition, there
vulnerabilities that depend on the misuse of supposedly
addresses, such as 'land' as described in [CA-97.28.Teardrop_Land].
To reduce the exposure of their customers to attacks that rely
forged source addresses ISPs should do the following. At
boundary router with each of their customers they should
filter all traffic going to the customer that has a source address
any of the addresses that have been assigned to that customer
The circumstances described in 4.3 in which ingress filtering isn'
feasible apply similarly to egress filtering
4.5 Route
Excessive routing updates can be leveraged by an attacker as a
load on which to build a Denial of Service attack. At the very
they will result in performance degradation
ISPs should filter the routing announcements they hear, for
to ignore routes to addresses allocated for private Internets,
avoid bogus routes and to implement "BGP Route Flap Dampening
[RFC2439] and aggregation policy
ISPs should implement techniques that reduce the risk of
excessive load on routing in other parts of the network.
include 'nailed up' routes, aggressive aggregation and
dampening, all of which lower the impact on others when your
routing changes in a way that isn't relevant to them
4.6 Directed
The IP protocol allows for directed broadcast, the sending of
packet across the network to be broadcast on to a specific subnet
Very few practical uses for this feature exist, but several
security attacks (primarily Denial of Service attacks making use
the packet multiplication effect of the broadcast) use it
Therefore, routers connected to a broadcast medium MUST NOT
configured to allow directed broadcasts onto that medium [RFC2644].
Killalea Best Current Practice [Page 8]
RFC 3013 Recommended ISP Security November 2000
5 Systems
The way an ISP manages their systems is crucial to the security
reliability of their network. A breach of their systems
minimally lead to degraded performance or functionality, but
lead to loss of data or the risk of traffic being eavesdropped (
leading to 'man-in-the-middle' attacks).
It's widely accepted that it's easier to build secure systems
different services (such as mail, news and web-hosting) are kept
separate systems
5.1 System
All systems that perform critical ISP functions such as mail,
and web-hosting, should be restricted such that access to them
only available to the administrators of those services. That
should be granted only following strong authentication, and
take place over an encrypted link. Only the ports on which
services listen should be reachable from outside of the ISP's
networks
ISPs should stay up to date for more secure methods of
services as they become available (e.g., IMAP/POP AUTHorize
for Simple Challenge/Response, [RFC2195]).
5.2 No Systems on Transit
Systems should not be attached to transit network segments
5.3 Open Mail
ISPs should take active steps to prevent their mail
from being used by 'spammers' to inject Unsolicited Bulk E-mail (UBE
while hiding the sender's identity [RFC2505]. While not
preventive steps are appropriate for every site, the most
site-appropriate methods should be used
ISPs should also strongly encourage their customers to take
necessary steps to prevent this activity on their own systems
5.4 Message
Message submissions should be authenticated using the AUTH
service extension as described in the "SMTP Service Extension
Authentication" [RFC2554].
Killalea Best Current Practice [Page 9]
RFC 3013 Recommended ISP Security November 2000
SMTP AUTH is preferred over IP address-based submission
in that it gives the ISP's customers the flexibility of being able
submit mail even when not connected through the ISP's network (
example, while at work), is more resistant to spoofing, and can
upgraded to newer authentication mechanisms as they become available
In addition, to facilitate the enforcement of security policy, it
strongly recommended that messages be submitted using the MAIL
port (587) as discussed in "Message Submission" [RFC2476],
than through the SMTP port (25). In this way the SMTP port (25)
be restricted to local delivery only
The reason for this is to be able to differentiate between
local delivery and relay (i.e., allow customers to send email via
ISP's SMTP service to arbitrary receivers on the Internet). Non
authenticated SMTP should only be allowed for local delivery
As more and more mail clients support both SMTP AUTH and the
submission port (either explicitly or by configuring the SMTP port),
ISPs may find it useful to require that customers submit
using both the submission port and SMTP AUTH; permitting only
mail on port 25.
These measures (SMTP AUTH and the submission port) not only
the ISP from serving as a UBE injection point via third-party relay
but also help in tracking accountability for message submission
the case where a customer sends UBE
6
[CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked
Connections",
ftp://info.cert.org/pub/cert_advisories
[CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks",
ftp://info.cert.org/pub/cert_advisories
[DPR1998] The UK "Data Protection Act 1998 (c. 29)",
http://www.hmso.gov.uk/acts/acts1998/
19980029.
[RFC1786] Bates, T., Gerich, E., Joncheray, L.,
Jouanigot, J., Karrenberg, D., Terpstra, M
and J. Yu, "Representation of IP
Policies in a Routing Registry (ripe-81++)",
RFC 1786, March 1995.
Killalea Best Current Practice [Page 10]
RFC 3013 Recommended ISP Security November 2000
[RFC1834] Gargano, J. and K. Weiss, "Whois and
Information Lookup Service", RFC 1834,
August 1995.
[RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P.
C. Weider, "Architecture of the WHOIS++
service", RFC 1835, August 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D.,
de Groot, G. J. and E. Lear, "
Allocation for Private Internets", BCP 5,
RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs
Indicate Requirement Levels", BCP 14,
2119, March 1997.
[RFC2142] Crocker, D., "Mailbox Names for
Services, Roles and Functions", RFC 2142,
May 1997.
[RFC2195] Klensin, J., Catoe, R. and P. Krumviede
"IMAP/POP AUTHorize Extension for
Challenge/Response", RFC 2195,
1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8,
RFC 2196, September 1997.
[RFC2350] Brownlee, N. and E. Guttman, "
for Computer Security Incident Response",
BCP 21, RFC 2350, June 1998.
[RFC2385] Heffernan, A., "Protection of BGP
via the TCP MD5 Signature Option", RFC 2385,
August 1998.
[RFC2439] Chandra R., Govindan R. and C. Villamizar
"BGP Route Flap Damping", RFC 2439,
1998.
[RFC2476] Gellens R. and J. Klensin, "
Submission", RFC 2476, December 1998.
[RFC2505] Lindberg, G., "Anti-Spam Recommendations
SMTP MTAs", BCP 30, RFC 2505, February 1999.
Killalea Best Current Practice [Page 11]
RFC 3013 Recommended ISP Security November 2000
[RFC2554] Myers, J., "SMTP Service Extension
Authentication", RFC 2554, March 1999.
[RFC2644] Senie, D., "Changing the Default
Directed Broadcasts in Routers", BCP 34,
2644, August 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network
Filtering: Defeating Denial of
Attacks which employ IP Source
Spoofing", BCP 38, RFC 2827, May 2000.
7
I gratefully acknowledge the constructive comments received
Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser,
Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski
Michael A. Patton, Don Stikvoort and Bill Woodcock
8 Security
This entire document discusses security issues
9 Author's
Tom
Lisi/n na Bro/
Be/al A/tha na
Co. Mhaigh
Phone: +1 206 266-2196
EMail: tomk@neart.
Killalea Best Current Practice [Page 12]
RFC 3013 Recommended ISP Security November 2000
10 Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Killalea Best Current Practice [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
