RFC 1173

Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet

๐Ÿ“… published August 1990, from ietf

Title Block โœจ

okay bestie, let's get the basics down first ๐Ÿ’…๐ŸŽ€ This is RFC 1173, called Responsibilities of Host and Network Managers, subtitled "A Summary of the "Oral Tradition" of the Internet" ๐Ÿฆ‹ It was written by J. Van Bokkelen of FTP Software, Inc., for the Network Working Group, and it's dated August 1990. It's an Informational RFC, so it's a set of conventions, not a standard. The title block doesn't list any RFCs it obsoletes or updates ๐ŸŒธ


Status of this Memo ๐Ÿงš

this informational RFC lays out the conventions that people in charge of networks and hosts on the Internet are supposed to follow ๐Ÿ’œ It's basically a summary of the "oral tradition" of the Internet on this subject.

[RFC Editor's note: This memo is the author's own take on these conventions. The RFC Editor expects this RFC to become a basis for official policies down the line.]

These conventions can be supplemented or changed by the policies of specific local and regional parts of the Internet. This RFC doesn't specify a standard, or a policy of the IAB. Distribution of this memo is unlimited ๐Ÿซถ

Table of Contents ๐Ÿ“š

Status of this Memo .............................................. 1
1. Basic Responsibilities......................................... 1
2. Responsibilities of Network Managers........................... 2
3. Responsibilities of Host System Managers....................... 2
4. Postmaster@foo.bar.baz......................................... 3
5. Problems and Resolutions....................................... 3
6. The Illusion of Security....................................... 4
7. Summary........................................................ 5
8. Security Considerations........................................ 5
9. Author's Address............................................... 5

1. Basic Responsibilities ๐ŸŒˆ

the Internet is a team effort ๐Ÿซถ and it only works if every user, host and router behaves reasonably. So the people in charge of Internet components MUST be aware of their responsibilities and pay attention to local conditions. They MUST also be reachable by both Internet mail and telephone, and they have to respond to problem reports and diagnostic efforts from other participants.

Even local problems that seem small and temporary, like system crashes or power failures, can have wide effects elsewhere in the network ๐Ÿ˜ญ Problems that need two or more responsible people working together to diagnose and fix them are pretty common. The tools, access and experience needed for efficient analysis also might not all live in one place.

This communal approach to managing and maintaining the Internet comes from its current decentralized organizational structure ๐Ÿฆ‹ That structure exists because it's cheap and responsive to different local needs. For the near term, it's our only real choice. The author doesn't see any chance that the government or private companies will build a monolithic, centralized, ubiquitous "Ma Datagram" network provider in this century ๐Ÿ’€

2. Responsibilities of Network Managers ๐Ÿ‘‘

One or more individuals are responsible for every IP net or subnet connected to the Internet. Their names, phone numbers and postal addresses MUST be given to the Internet NIC (or to the NIC of the local or regional transit network) before the network first connects to the Internet. Updates and corrections MUST be provided in a timely manner for as long as the net stays connected ๐ŸŽ€

To handle problems that come up, a network manager must have either:

  • A. System management access privileges on every host and router connected to the local network, or:
  • B. The authority and access to power off, re-boot, physically disconnect, or disable forwarding of IP datagrams from any individual host system that might be misbehaving.

For all networks, a network manager who can exercise this level of control MUST be reachable by telephone 8 hours a day, 5 days a week. For nets carrying transit traffic, a network manager SHOULD be reachable by telephone 24 hours a day ๐Ÿ”ฅ

3. Responsibilities of Host System Managers ๐Ÿ“

One or more individuals must be responsible for every host connected to the Internet. That person MUST have the authority, access and tools needed to configure, operate and control access to the system. For important timesharing hosts, primary domain name servers and mail relays or gateways, the responsible individual(s) SHOULD be reachable by telephone 24 hours a day, 7 days a week โœจ

For less-important timesharing hosts or single-user PCs and workstations, the responsible individual(s) MUST be ready for the possibility that their network manager has to step in while they're away, if fixing an Internet problem requires it ๐Ÿ™ˆ

4. Postmaster@foo.bar.baz ๐Ÿ’Œ

Every Internet host that handles mail beyond the local network MUST maintain a mailbox named postmaster. In general, this shouldn't just forward mail somewhere else. It should be read by a system maintainer who's logged in to the machine. This mailbox SHOULD be read at least 5 days a week, and arrangements MUST be made to handle incoming mail when the normal maintainer is away ๐Ÿ“ฌ

A machine's postmaster is the usual contact for mail delivery problems. Most traffic on the Internet's long-haul segments is mail, so a local problem can have big effects elsewhere. Some problems are system-wide, like a full disk or file system, or a mailer or domain name server that's hung, crashed or confused. Others are specific to a user or mailing list, like wrong aliasing or forwarding, or an exceeded quota ๐Ÿงš

When a remote machine's maintainer runs into a delivery problem, they'll usually mail postmaster. Also, postmaster is normally listed in the reply-to: field of automatically generated error messages (undeliverable because a user name doesn't exist, unable to forward, malformed header, and so on). If this mailbox isn't read in a timely way, a lot of mail can get lost or bounced back to its senders ๐Ÿ˜ฑ

5. Problems and Resolutions ๐Ÿ”

Better network management tools might someday let a network maintainer detect and fix most problems before users notice. For now, though, everyday users of networking services are the front line ๐Ÿซก No responsible person should let their "dumb-question" filter get too strict. Reports like "I haven't gotten any mumblefrotz mail for a week..." or "I could get there this morning, but not now..." should always get prompt attention ๐Ÿ’œ

There are three basic classes of problems that can have network-wide scope: user-related, host-related and network-related.

  • A. User-related problems can range from bouncing mail or rude behavior on mailing lists to more serious issues like privacy violations, break-in attempts or vandalism.
  • B. Host-related problems may include misconfigured software, obsolete or buggy software, and security holes.
  • C. Network-related problems are mostly about routing: incorrect connectivity advertisements, routing loops and black holes can all have major impacts. Mechanisms usually exist for handling router or link failure, but problems short of outright failure can also have serious effects ๐ŸŒธ

Each class has its own characteristics. User-related problems can usually be solved with education, but system managers should also know applicable federal and state law. Privacy violations or "cracking" attempts have always been grounds for pulling a user's account, and now they can also lead to prosecution ๐Ÿšจ Host-related problems can usually be fixed by reconfiguring or upgrading the software. Sometimes the manufacturer needs to be told about a bug, or pressured into doing something about it. Bugs that can't be fixed might be serious enough to require partial or total denial of service to the offending system. Network-related problems have similar levels of escalation, and the solution of last resort is ostracism of the offending net ๐Ÿ’…

6. The Illusion of Security ๐Ÿ”

Every host and network manager MUST be aware that the Internet as it's currently built is not secure ๐Ÿ˜ญ At the protocol level, far more effort has gone into interoperability, reliability and convenience than into security, although that's changing. Recent events have made software developers and vendors more sensitive to security, both in configuration and in the underlying implementation. But it's still unclear how much long-term effect this will have. Meanwhile, the existing system survives because all responsible people cooperate ๐Ÿซถ

Security is subjective. One site might see idle curiosity where another sees a hostile probe. Since the Internet's existence ultimately depends on being useful to all members of the community, managers need to be willing to accept and act on other sites' security concerns, warning or denying access to offending users. The offended site, in turn, has to be reasonable in its demands. Someone who set off an alarm while idly checking whether the sendmail "DEBUG" hole was closed on a "sensitive" host should probably be warned, not prosecuted ๐Ÿ™ˆ

Because Internet security issues may require local managers to contact their users, or to deny an offending individual or group access to other sites, mechanisms need to exist that allow this. So Internet sites SHOULD NOT have "general use" accounts, or "open" (no password) terminal servers that can reach the rest of the Internet ๐Ÿšซ

On the flip side, the "sensitive" sites MUST be aware that over the long term it's impossible to deny Internet access to crackers, disgruntled former employees, unscrupulous competitors or agents of other countries. Getting an offender flushed is at best a stop-gap, buying a day or an hour while the security holes under attack get closed. So each host's manager is ultimately responsible for its security. The more "sensitive" the application or data, the more intimate the manager must be with the host's operating system, network software and their foibles ๐Ÿง

7. Summary ๐ŸŽ€

The heart of the Internet is the unique community of interest that spans its users, operators, maintainers and suppliers. Awareness of, and buy-in to, the shared interest in a usable Internet is vital to its survival and growth ๐Ÿ’– The simple conventions here should be supplemented with common sense as needed to get there โœจ

8. Security Considerations ๐Ÿ’€

Security issues are discussed in Sections 5 and 6. Honestly, the whole vibe of this RFC is security, so go read those sections ๐Ÿ”ฅ

9. Author's Address ๐Ÿ“ฎ

James B. VanBokkelen
FTP Software Inc.
26 Princess St.
Wakefield, MA  01880

Phone:  617-246-0900

EMail: jbvb@ftp.com
๐Ÿ“ฆ where this page comes from