RFC 3013

Recommended Internet Service Provider Security Services and Procedures

📅 published November 2000, from ietf

okay bestie, this is the one. RFC 3013 is a Best Current Practice (that's BCP 46 ✨), written by T. Killalea from neart.org, and it was published in November 2000. It's a Best Current Practice, not a standard, so it's advice for the internet community. It doesn't list anything it obsoletes or updates, so it's standing on its own 💅.

Status of this Memo 🌸

okay so this document is an Internet Best Current Practice for the internet community 🦋. The author is basically asking everyone to talk back with discussion and suggestions for making it better. And the best part? Distribution of this memo is unlimited, so share it with everyone 💜.

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

1. Abstract 🧚

so the whole point of this doc is to spell out what the engineering community (aka the IETF 👑) expects from Internet Service Providers (ISPs) when it comes to security 🔐.

it is NOT trying to be a rulebook that fits every single ISP, though 🙅‍♀️. it's more like raising awareness of what the community expects, and giving everyone a framework for talking about security expectations with current and future providers 🫶.

1. Introduction ✨

the purpose of this document is to express what the engineering community (aka the IETF) expects from Internet Service Providers (ISPs) when it comes to security. this document is written for ISPs 💖.

the community hopes that by telling ISPs what they're hoping for, ISPs will get proactive. the dream is security becomes a priority, and something they're proud to show off when they sell their services 💅✨.

under no circumstances is this document trying to dictate business practices. not its job, bestie 🙅‍♀️.

when this doc says ISPs, it means organisations in the business of providing Internet connectivity or other Internet services. that includes (but isn't limited to) web hosting services, content providers and e-mail services 📬. organisations that provide those services just for their own purposes are NOT counted as ISPs in this definition 🙈.

this document is offered as a set of recommendations to ISPs about what security and attack management arrangements should be supported. it's also advice for users about what they should expect from a high quality service provider 🌈. it is in no sense normative in its own right, so it's not binding on anyone 🫠. it's likely to get dated over time, and other expectations may show up. still, it's a snapshot of what a group of professionals in the field recommended at one 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] 🔑. these are the special words that tell you how strict something is, so don't skip them 👀.

2. Communication 💬

the community's most significant security-related expectations of ISPs are about availability of communication channels for dealing with security incidents 🚨. like, can people actually reach someone when things go wrong? that's the big one 😭.

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/) 🔗. a cute little security page, honestly 🥰.

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 🫡. no ghost contact info allowed, periodt 👻🚫.

2.2. Information Sharing 🤫

ISPs SHOULD have clear policies and procedures on sharing 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 📰. basically, know who gets told what, and when 🗂️.

ISPs should have processes in place to deal with security incidents that traverse the boundaries between them and other ISPs 🌉. when the problem crosses into someone else's network, you need a plan for that too 🤝.

2.3. Secure Channels 🔒

ISPs SHOULD be able to conduct such communication over a secure channel 🔐. but heads up, in some jurisdictions secure channels might not be permitted, so it's not always a yes 🙃.

2.4. Notification of Vulnerabilities and Reporting of Incidents 🚩

ISPs SHOULD be proactive in notifying customers of security vulnerabilities in the services they provide 📣. also, as new vulnerabilities in systems and software are discovered, they should indicate whether their services are threatened by these risks 👀. no hiding it, bestie 💅.

when security incidents happen that affect components of an ISP's infrastructure, the ISP should promptly report the following 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 already have procedures for telling customers about outages and service degradation 📡. it's reasonable for the ISP to use those same channels for reporting security-related incidents ♻️. just know that in these cases, the customer's security point of contact might not be the person who gets notified. instead, the normal point of contact will receive the report 📨. customers should be aware of this and make sure to route those notifications appropriately 🧠✨.

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 📢. they should also clearly document their capability to respond to reported incidents, and should indicate if there's 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 use the ISP's CSIRT 🙅‍♀️. ISP CSIRTs are often an added-cost service, with the team defining its constituency as only those who specifically subscribe to (and perhaps pay for) Incident Response services 💸. so it's not a free-for-all, babe 💀.

so it's important for ISPs to publish what incident response and security resources they make available to customers 📚. that way, customers can define their incident response escalation chain BEFORE an incident occurs 🧯. planning ahead is everything 😤✨.

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 Internet connectivity, that contract should be governed by an AUP 🤝. the AUP should be reviewed each time the contract is up for renewal. on top of that, 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 of traffic allowed on the networks 🚦. it should be as explicit as possible so there's no ambiguity or misunderstanding 🫠. for example, an AUP might prohibit IP spoofing 🎭.

3.1. Announcement of Policy 📣

in addition to communicating their AUP to customers, ISPs should publish their policy in a public place, such as their web site 🌐. that way the community can see what the ISP considers appropriate, and can know what action to expect if there's inappropriate behaviour 👀✨.

3.2. Sanctions ⚖️

an AUP should be clear about what sanctions will be enforced in the event of inappropriate behaviour 🚫. no vague threats, bestie 💅.

3.3. Data Protection 🗝️

many jurisdictions have Data Protection Legislation 🌍. where that legislation applies, ISPs should consider the personal data they hold and, if necessary, register themselves as Data Controllers. they should also be prepared to only use the data in accordance with the terms of the legislation 🧾. because the Internet is global, ISPs 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 🗂️

Okay so ISPs are usually the ones keeping the data in big global repositories like the Internet Routing Registry (IRR) and the APNIC, ARIN and RIPE databases 💅. Updates to that data should only be possible using strong authentication 🔐, so no random strangers editing it, bestie!

ISPs should publicly register the address space they assign to their customers 📇✨. That way there's more specific contact info for the delegated space, and people can actually find who to ask 🫶.

4.2. Routing Infrastructure 🛣️

An ISP's ability to send traffic to the right destination may depend on routing policy that's configured in routing registries [RFC1786] 🗺️. If that's the case, and the registry supports it, they should make sure the registry info they maintain can only be updated using strong authentication, and that the power to make updates is properly restricted 👑. Main character energy means guarding the keys!

Due care should also be taken when deciding whose routing announcements you trust more, if there's a choice of routes to a destination 🤔. In the past, bogus announcements have caused traffic to get 'black holed' 🕳️, or even worse, hijacked 😭.

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

4.3. Ingress Filtering on Source Address 🚪

This kind of filtering goes from the edge site (customer) out to the Internet 🌐.

Attackers love covering their tracks with forged source addresses 🥷. To throw people off their trail, the source address they pick will usually belong to an innocent remote site, or even come from the addresses reserved for private Internets [RFC1918] 🙈. Forged source addresses also show up a lot in spoof-based attacks that try to abuse a trust relationship between hosts 💀.

To cut down on attacks that depend on forged source addresses, ISPs should do the following 📝. At the boundary router with each customer, they should proactively filter all traffic coming from that customer whose source address is anything other than the addresses assigned to that customer 🛡️. For a deeper dive on this topic, check out [RFC2827] 📚.

There are (rare) situations where ingress filtering just isn't possible right now, like on large aggregation routers that can't handle the extra load of running packet filters 😩. Filtering can also cause trouble for mobile users 📱. So while using this technique to stop spoofing is strongly encouraged 🫶, it may not always be feasible.

In those rare cases where ingress filtering at the customer-to-ISP interface isn't possible, the customer should be encouraged to set up ingress filtering inside their own network 🏠. In general, filtering should happen as close to the actual hosts as possible 🎯.

4.4. Egress Filtering on Source Address 📬

This one goes the other way: from the Internet into the edge site (customer) 🌍.

Tons of applications on the Internet today trust other hosts based only on ip address, like the Berkeley 'r' commands 😬. They're open to IP spoofing, as described in [CA-95.01.IP.spoofing] 🫠. There are also vulnerabilities that depend on messing with supposedly local addresses, like 'land' as described in [CA-97.28.Teardrop_Land] 💥.

To lower their customers' exposure to attacks that rely on forged source addresses, ISPs should do the following ✨. At the boundary router with each customer, they should proactively filter all traffic going to that customer whose source address is any of the addresses assigned to that customer 🧱.

The situations described in 4.3 where ingress filtering isn't feasible apply to egress filtering too 🔁.

4.5. Route Filtering 🧹

Excessive routing updates can be used by an attacker as a base load to build a Denial of Service attack on top of 🌊. At the very least, they'll cause performance to degrade 🐢.

ISPs should filter the routing announcements they hear 👂. For example, they can ignore routes to addresses allocated for private Internets, avoid bogus routes, implement "BGP Route Flap Dampening" [RFC2439], and apply aggregation policy 🧽.

ISPs should also use techniques that reduce the risk of piling excessive load onto routing in other parts of the network 🫧. These include 'nailed up' routes, aggressive aggregation and route dampening. All of these lower the impact on others when your internal routing changes in a way that doesn't matter to them 💜.

4.6. Directed Broadcast 📢

The IP protocol allows directed broadcast, which means sending a packet across the network so it gets broadcast onto one specific subnet 📡. There are very few practical uses for this feature, but several security attacks use it, mostly Denial of Service attacks that take advantage of the packet multiplication effect of broadcast 😱. Because of that, routers connected to a broadcast medium MUST NOT be configured to allow directed broadcasts onto that medium [RFC2644] 🚫. This is a hard no, babe!

⚠️ Routers connected to a broadcast medium MUST NOT allow directed broadcasts onto it. Non-negotiable, periodt 💀.

5. Systems Infrastructure 🖥️

The way an ISP manages its systems is super crucial to the security and reliability of its network 🔒. A breach of those systems might only lead to degraded performance or functionality, but it could also lead to lost data or the risk of traffic being eavesdropped (which can turn into 'man-in-the-middle' attacks) 😭.

It's widely accepted that it's easier to build secure systems when different services, like mail, news and web-hosting, live on separate systems 🧁✨.

5.1. System Management 🧑‍💻

All systems that perform critical ISP functions, like mail, news and web-hosting, should be locked down so that only the administrators of those services can access them 🗝️. That access should only be granted after strong authentication, and it should happen over an encrypted link 🔐. Only the ports those services listen on should be reachable from outside the ISP's systems networks 🚧.

ISPs should keep up with more secure ways of providing services as they become available, like the IMAP/POP AUTHorize Extension for Simple Challenge/Response [RFC2195] 🆕🌸.

5.2. No Systems on Transit Networks 🛤️

Systems should not be attached to transit network segments 🙅‍♀️. Keep those vibes clean!

5.3. Open Mail Relay 📮

ISPs should take active steps to stop their mail infrastructure from being used by 'spammers' to inject Unsolicited Bulk E-mail (UBE) while hiding the sender's identity [RFC2505] 🗑️. Not every preventive step fits every site, so the most effective site-appropriate methods should be used 🎯.

ISPs should also strongly encourage their customers to take the necessary steps to stop this on their own systems 🫶.

5.4. Message Submission 📨

Message submissions should be authenticated using the AUTH SMTP service extension, as described in the "SMTP Service Extension for Authentication" [RFC2554] 🔐💖.

SMTP AUTH is preferred over IP address-based submission restrictions 🏆. Why? Because it lets customers submit mail even when they aren't connected through the ISP's network (like when they're at work) 💼, it's more resistant to spoofing 🛡️, and it can be upgraded to newer authentication mechanisms as those show up 🆙.

Also, to help enforce security policy, it is strongly recommended that messages be submitted through the MAIL SUBMIT port (587) as discussed in "Message Submission" [RFC2476], rather than through the SMTP port (25) 📬. That way, the SMTP port (25) can be restricted to local delivery only 🏠.

The point of all this is to tell apart inbound local delivery from relay, which means letting customers send email through the 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 message submission port (either directly, or by configuring the SMTP port), ISPs may find it useful to require customers to submit messages using both the submission port and SMTP AUTH, while only permitting inbound mail on port 25 📥✨.

These measures (SMTP AUTH and the submission port) do more than protect the ISP from being a UBE injection point via third-party relay 🛑. They also help track accountability for message submission when a customer sends UBE 🕵️‍♀️💅.

6. References ✨

okay bestie, the reading list is here 📚🫶 every source the RFC leans on, with all its details, so you can go check them yourself

  • [CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal 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.htm 🇬🇧
  • [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, March 1995. 🗂️
  • [RFC1834] Gargano, J. and K. Weiss, "Whois and Network Information Lookup Service", RFC 1834, August 1995. 🔎
  • [RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P. and 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, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 🏠
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
  • [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997. 📬
  • [RFC2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. 🔐
  • [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. 📖
  • [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998. 🚨
  • [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 🛡️
  • [RFC2439] Chandra R., Govindan R. and C. Villamizar, "BGP Route Flap Damping", RFC 2439, November 1998. 🌊
  • [RFC2476] Gellens R. and J. Klensin, "Message Submission", RFC 2476, December 1998. 📨
  • [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999. 🚫📧
  • [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. 🪪
  • [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999. 📡
  • [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. 🧱

7. Acknowledgements 🫶

the people in this section gave really constructive comments on the doc, so huge thank-yous to Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, Michael A. Patton, Don Stikvoort and Bill Woodcock 💖✨

8. Security Considerations 💀

okay this one is short but it is SERIOUS 😭 the whole entire document is about security issues. every section in here is a security section, so please read the rest of it with that in mind 🔥🙈

9. Author's Address 🎀

the author is Tom Killalea, and here's how to reach him:

Tom Killalea
Lisi/n na Bro/n
Be/al A/tha na Muice
Co. Mhaigh Eo
IRELAND

Phone: +1 206 266-2196
EMail: tomk@neart.org

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

okay so the legal part, but make it cute: this document and its translations can be copied and handed out to others, and people can write derivative works that comment on it or explain it or help people implement it. they can be prepared, copied, published and distributed, in whole or in part, with no restrictions at all, as long as the copyright notice and this paragraph stay on every copy and derivative work 🦋

BUT the document itself can't be modified in any way. you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. the one exception is when you need it to develop Internet standards, and then you have to follow the copyright procedures in the Internet Standards process. you're also allowed to translate it into languages other than English 🌸

the permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them 🧚

and the boring-but-important bit, verbatim because it's legal:

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🍓

last but not least, funding for the RFC Editor function is currently provided by the Internet Society. thank you for keeping the lights on, IS 🫶✨

📦 where this page comes from