diff options
Diffstat (limited to 'doc/rfc/rfc3871.txt')
| -rw-r--r-- | doc/rfc/rfc3871.txt | 4539 |
1 files changed, 4539 insertions, 0 deletions
diff --git a/doc/rfc/rfc3871.txt b/doc/rfc/rfc3871.txt new file mode 100644 index 0000000..0580fdc --- /dev/null +++ b/doc/rfc/rfc3871.txt @@ -0,0 +1,4539 @@ + + + + + + +Network Working Group G. Jones, Ed. +Request for Comments: 3871 The MITRE Corporation +Category: Informational September 2004 + + + Operational Security Requirements for Large + Internet Service Provider (ISP) IP Network Infrastructure + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document defines a list of operational security requirements for + the infrastructure of large Internet Service Provider (ISP) IP + networks (routers and switches). A framework is defined for + specifying "profiles", which are collections of requirements + applicable to certain network topology contexts (all, core-only, + edge-only...). The goal is to provide network operators a clear, + concise way of communicating their security requirements to vendors. + + + + + + + + + + + + + + + + + + + + + + + + +Jones Informational [Page 1] + +RFC 3871 Operational Security Requirements September 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1. Goals. . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.4. Definition of a Secure Network . . . . . . . . . . . . . 6 + 1.5. Intended Audience. . . . . . . . . . . . . . . . . . . . 6 + 1.6. Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.7. Intended Use . . . . . . . . . . . . . . . . . . . . . . 7 + 1.8. Definitions. . . . . . . . . . . . . . . . . . . . . . . 7 + 2. Functional Requirements . . . . . . . . . . . . . . . . . . . 11 + 2.1. Device Management Requirements . . . . . . . . . . . . . 11 + 2.1.1. Support Secure Channels For Management. . . . . 11 + 2.2. In-Band Management Requirements. . . . . . . . . . . . . 12 + 2.2.1. Use Cryptographic Algorithms Subject To + Open Review . . . . . . . . . . . . . . . . . . 12 + 2.2.2. Use Strong Cryptography . . . . . . . . . . . . 13 + 2.2.3. Use Protocols Subject To Open Review For + Management. . . . . . . . . . . . . . . . . . . 14 + 2.2.4. Allow Selection of Cryptographic Parameters . . 15 + 2.2.5. Management Functions Should Have Increased + Priority. . . . . . . . . . . . . . . . . . . . 16 + 2.3. Out-of-Band (OoB) Management Requirements . . . . . . . 16 + 2.3.1. Support a 'Console' Interface . . . . . . . . . 17 + 2.3.2. 'Console' Communication Profile Must Support + Reset . . . . . . . . . . . . . . . . . . . . . 19 + 2.3.3. 'Console' Requires Minimal Functionality of + Attached Devices. . . . . . . . . . . . . . . . 19 + 2.3.4. 'Console' Supports Fall-back Authentication . . 20 + 2.3.5. Support Separate Management Plane IP + Interfaces. . . . . . . . . . . . . . . . . . . 21 + 2.3.6. No Forwarding Between Management Plane And Other + Interfaces. . . . . . . . . . . . . . . . . . . 21 + 2.4. Configuration and Management Interface Requirements. . . 22 + 2.4.1. 'CLI' Provides Access to All Configuration and + Management Functions. . . . . . . . . . . . . . 22 + 2.4.2. 'CLI' Supports Scripting of Configuration . . . 23 + 2.4.3. 'CLI' Supports Management Over 'Slow' Links . . 24 + 2.4.4. 'CLI' Supports Idle Session Timeout . . . . . . 25 + 2.4.5. Support Software Installation . . . . . . . . . 25 + 2.4.6. Support Remote Configuration Backup . . . . . . 27 + 2.4.7. Support Remote Configuration Restore. . . . . . 27 + 2.4.8. Support Text Configuration Files. . . . . . . . 28 + 2.5. IP Stack Requirements. . . . . . . . . . . . . . . . . . 29 + 2.5.1. Ability to Identify All Listening Services. . . 29 + 2.5.2. Ability to Disable Any and All Services . . . . 30 + + + + +Jones Informational [Page 2] + +RFC 3871 Operational Security Requirements September 2004 + + + 2.5.3. Ability to Control Service Bindings for + Listening Services. . . . . . . . . . . . . . . 30 + 2.5.4. Ability to Control Service Source Addresses . . 31 + 2.5.5. Support Automatic Anti-spoofing for + Single-Homed Networks . . . . . . . . . . . . . 32 + 2.5.6. Support Automatic Discarding Of Bogons and + Martians. . . . . . . . . . . . . . . . . . . . 33 + 2.5.7. Support Counters For Dropped Packets. . . . . . 34 + 2.6. Rate Limiting Requirements . . . . . . . . . . . . . . . 35 + 2.6.1. Support Rate Limiting . . . . . . . . . . . . . 35 + 2.6.2. Support Directional Application Of Rate + Limiting Per Interface. . . . . . . . . . . . . 36 + 2.6.3. Support Rate Limiting Based on State. . . . . . 36 + 2.7. Basic Filtering Capabilities . . . . . . . . . . . . . . 37 + 2.7.1. Ability to Filter Traffic . . . . . . . . . . . 37 + 2.7.2. Ability to Filter Traffic TO the Device . . . . 37 + 2.7.3. Ability to Filter Traffic THROUGH the Device. . 38 + 2.7.4. Ability to Filter Without Significant + Performance Degradation . . . . . . . . . . . . 38 + 2.7.5. Support Route Filtering . . . . . . . . . . . . 39 + 2.7.6. Ability to Specify Filter Actions . . . . . . . 40 + 2.7.7. Ability to Log Filter Actions . . . . . . . . . 40 + 2.8. Packet Filtering Criteria. . . . . . . . . . . . . . . . 41 + 2.8.1. Ability to Filter on Protocols. . . . . . . . . 41 + 2.8.2. Ability to Filter on Addresses. . . . . . . . . 42 + 2.8.3. Ability to Filter on Protocol Header Fields . . 42 + 2.8.4. Ability to Filter Inbound and Outbound. . . . . 43 + 2.9. Packet Filtering Counter Requirements. . . . . . . . . . 43 + 2.9.1. Ability to Accurately Count Filter Hits . . . . 43 + 2.9.2. Ability to Display Filter Counters. . . . . . . 44 + 2.9.3. Ability to Display Filter Counters per Rule . . 45 + 2.9.4. Ability to Display Filter Counters per Filter + Application . . . . . . . . . . . . . . . . . . 45 + 2.9.5. Ability to Reset Filter Counters. . . . . . . . 46 + 2.9.6. Filter Counters Must Be Accurate. . . . . . . . 47 + 2.10. Other Packet Filtering Requirements . . . . . . . . . . 47 + 2.10.1. Ability to Specify Filter Log Granularity . . . 47 + 2.11. Event Logging Requirements . . . . . . . . . . . . . . . 48 + 2.11.1. Logging Facility Uses Protocols Subject To + Open Review . . . . . . . . . . . . . . . . . . 48 + 2.11.2. Logs Sent To Remote Servers . . . . . . . . . . 49 + 2.11.3. Ability to Select Reliable Delivery . . . . . . 49 + 2.11.4. Ability to Log Locally. . . . . . . . . . . . . 50 + 2.11.5. Ability to Maintain Accurate System Time. . . . 50 + 2.11.6. Display Timezone And UTC Offset . . . . . . . . 51 + 2.11.7. Default Timezone Should Be UTC. . . . . . . . . 52 + 2.11.8. Logs Must Be Timestamped. . . . . . . . . . . . 52 + 2.11.9. Logs Contain Untranslated IP Addresses. . . . . 53 + + + +Jones Informational [Page 3] + +RFC 3871 Operational Security Requirements September 2004 + + + 2.11.10. Logs Contain Records Of Security Events . . . . 54 + 2.11.11. Logs Do Not Contain Passwords . . . . . . . . . 55 + 2.12. Authentication, Authorization, and Accounting (AAA) + Requirements . . . . . . . . . . . . . . . . . . . . . . 55 + 2.12.1. Authenticate All User Access. . . . . . . . . . 55 + 2.12.2. Support Authentication of Individual Users. . . 56 + 2.12.3. Support Simultaneous Connections. . . . . . . . 56 + 2.12.4. Ability to Disable All Local Accounts . . . . . 57 + 2.12.5. Support Centralized User Authentication + Methods . . . . . . . . . . . . . . . . . . . . 57 + 2.12.6. Support Local User Authentication Method. . . . 58 + 2.12.7. Support Configuration of Order of + Authentication Methods . . . . . . . . . . . . 59 + 2.12.8. Ability To Authenticate Without Plaintext + Passwords . . . . . . . . . . . . . . . . . . . 59 + 2.12.9. No Default Passwords. . . . . . . . . . . . . . 60 + 2.12.10. Passwords Must Be Explicitly Configured Prior + To Use. . . . . . . . . . . . . . . . . . . . . 60 + 2.12.11. Ability to Define Privilege Levels. . . . . . . 61 + 2.12.12. Ability to Assign Privilege Levels to Users . . 62 + 2.12.13. Default Privilege Level Must Be 'None'. . . . . 62 + 2.12.14. Change in Privilege Levels Requires + Re-Authentication . . . . . . . . . . . . . . . 63 + 2.12.15. Support Recovery Of Privileged Access . . . . . 64 + 2.13. Layer 2 Devices Must Meet Higher Layer Requirements. . . 65 + 2.14. Security Features Must Not Cause Operational Problems. . 65 + 2.15. Security Features Should Have Minimal Performance + Impact . . . . . . . . . . . . . . . . . . . . . . . . . 66 + 3. Documentation Requirements . . . . . . . . . . . . . . . . . . 67 + 3.1. Identify Services That May Be Listening. . . . . . . . . 67 + 3.2. Document Service Defaults. . . . . . . . . . . . . . . . 67 + 3.3. Document Service Activation Process. . . . . . . . . . . 68 + 3.4. Document Command Line Interface. . . . . . . . . . . . . 68 + 3.5. 'Console' Default Communication Profile Documented . . . 69 + 4. Assurance Requirements . . . . . . . . . . . . . . . . . . . . 69 + 4.1. Identify Origin of IP Stack. . . . . . . . . . . . . . . 70 + 4.2. Identify Origin of Operating System. . . . . . . . . . . 70 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 71 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 71 + 6.2. Informative References . . . . . . . . . . . . . . . . . 74 + Appendices + A. Requirement Profiles . . . . . . . . . . . . . . . . . . . . . 75 + A.1. Minimum Requirements Profile . . . . . . . . . . . . . . 75 + A.2. Layer 3 Network Edge Profile . . . . . . . . . . . . . . 78 + B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 80 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 81 + + + +Jones Informational [Page 4] + +RFC 3871 Operational Security Requirements September 2004 + + +1. Introduction + +1.1. Goals + + This document defines a list of operational security requirements for + the infrastructure of large IP networks (routers and switches). The + goal is to provide network operators a clear, concise way of + communicating their security requirements to equipment vendors. + +1.2. Motivation + + Network operators need tools to ensure that they are able to manage + their networks securely and to insure that they maintain the ability + to provide service to their customers. Some of the threats are + outlined in section 3.2 of [RFC2196]. This document enumerates + features which are required to implement many of the policies and + procedures suggested by [RFC2196] in the context of the + infrastructure of large IP-based networks. Also see [RFC3013]. + +1.3. Scope + + The scope of these requirements is intended to cover the managed + infrastructure of large ISP IP networks (e.g., routers and switches). + Certain groups (or "profiles", see below) apply only in specific + situations (e.g., edge-only). + + The following are explicitly out of scope: + + o general purpose hosts that do not transit traffic including + infrastructure hosts such as name/time/log/AAA servers, etc., + + o unmanaged devices, + + o customer managed devices (e.g., firewalls, Intrusion Detection + System, dedicated VPN devices, etc.), + + o SOHO (Small Office, Home Office) devices (e.g., personal + firewalls, Wireless Access Points, Cable Modems, etc.), + + o confidentiality of customer data, + + o integrity of customer data, + + o physical security. + + This means that while the requirements in the minimum profile (and + others) may apply, additional requirements have not be added to + account for their unique needs. + + + +Jones Informational [Page 5] + +RFC 3871 Operational Security Requirements September 2004 + + + While the examples given are written with IPv4 in mind, most of the + requirements are general enough to apply to IPv6. + +1.4. Definition of a Secure Network + + For the purposes of this document, a secure network is one in which: + + o The network keeps passing legitimate customer traffic + (availability). + + o Traffic goes where it is supposed to go, and only where it is + supposed to go (availability, confidentiality). + + o The network elements remain manageable (availability). + + o Only authorized users can manage network elements (authorization). + + o There is a record of all security related events (accountability). + + o The network operator has the necessary tools to detect and respond + to illegitimate traffic. + +1.5. Intended Audience + + There are two intended audiences: the network operator who selects, + purchases, and operates IP network equipment, and the vendors who + create them. + +1.6. Format + + The individual requirements are listed in the three sections below. + + o Section 2 lists functional requirements. + + o Section 3 lists documentation requirements. + + o Section 4 lists assurance requirements. + + Within these areas, requirements are grouped in major functional + areas (e.g., logging, authentication, filtering, etc.) + + Each requirement has the following subsections: + + o Requirement (what) + + o Justification (why) + + o Examples (how) + + + +Jones Informational [Page 6] + +RFC 3871 Operational Security Requirements September 2004 + + + o Warnings (if applicable) + + The requirement describes a policy to be supported by the device. + The justification tells why and in what context the requirement is + important. The examples section is intended to give examples of + implementations that may meet the requirement. Examples cite + technology and standards current at the time of this writing. See + [RFC3631]. It is expected that the choice of implementations to meet + the requirements will change over time. The warnings list + operational concerns, deviation from standards, caveats, etc. + + Security requirements will vary across different device types and + different organizations, depending on policy and other factors. A + desired feature in one environment may be a requirement in another. + Classifications must be made according to local need. + + In order to assist in classification, Appendix A defines several + requirement "profiles" for different types of devices. Profiles are + concise lists of requirements that apply to certain classes of + devices. The profiles in this document should be reviewed to + determine if they are appropriate to the local environment. + +1.7. Intended Use + + It is anticipated that the requirements in this document will be used + for the following purposes: + + o as a checklist when evaluating networked products, + + o to create profiles of different subsets of the requirements which + describe the needs of different devices, organizations, and + operating environments, + + o to assist operators in clearly communicating their security + requirements, + + o as high level guidance for the creation of detailed test plans. + +1.8. Definitions + + RFC 2119 Keywords + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" + in this document are to be interpreted as described in [RFC2119]. + + + + + + +Jones Informational [Page 7] + +RFC 3871 Operational Security Requirements September 2004 + + + The use of the RFC 2119 keywords is an attempt, by the editor, to + assign the correct requirement levels ("MUST", "SHOULD", + "MAY"...). It must be noted that different organizations, + operational environments, policies and legal environments will + generate different requirement levels. Operators and vendors + should carefully consider the individual requirements listed here + in their own context. One size does not fit all. + + Bogon. + + A "Bogon" (plural: "bogons") is a packet with an IP source address + in an address block not yet allocated by IANA or the Regional + Internet Registries (ARIN, RIPE, APNIC...) as well as all + addresses reserved for private or special use by RFCs. See + [RFC3330] and [RFC1918]. + + CLI. + + Several requirements refer to a Command Line Interface (CLI). + While this refers at present to a classic text oriented command + interface, it is not intended to preclude other mechanisms which + may meet all the requirements that reference "CLI". + + Console. + + Several requirements refer to a "Console". The model for this is + the classic RS232 serial port which has, for the past 30 or more + years, provided a simple, stable, reliable, well-understood and + nearly ubiquitous management interface to network devices. Again, + these requirements are intended primarily to codify the benefits + provided by that venerable interface, not to preclude other + mechanisms that meet all the same requirements. + + Filter. + + In this document, a "filter" is defined as a group of one or more + rules where each rule specifies one or more match criteria as + specified in Section 2.8. + + In-Band management. + + "In-Band management" is defined as any management done over the + same channels and interfaces used for user/customer data. + Examples would include using SSH for management via customer or + Internet facing network interfaces. + + + + + + +Jones Informational [Page 8] + +RFC 3871 Operational Security Requirements September 2004 + + + High Resolution Time. + + "High resolution time" is defined in this document as "time having + a resolution greater than one second" (e.g., milliseconds). + + IP. + + Unless otherwise indicated, "IP" refers to IPv4. + + Management. + + This document uses a broad definition of the term "management". + In this document, "management" refers to any authorized + interaction with the device intended to change its operational + state or configuration. Data/Forwarding plane functions (e.g., + the transit of customer traffic) are not considered management. + Control plane functions such as routing, signaling and link + management protocols and management plane functions such as remote + access, configuration and authentication are considered to be + management. + + Martian. + + Per [RFC1208] "Martian: Humorous term applied to packets that turn + up unexpectedly on the wrong network because of bogus routing + entries. Also used as a name for a packet which has an altogether + bogus (non-registered or ill-formed) Internet address." For the + purposes of this document Martians are defined as "packets having + a source address that, by application of the current forwarding + tables, would not have its return traffic routed back to the + sender." "Spoofed packets" are a common source of martians. + + Note that in some cases, the traffic may be asymmetric, and a + simple forwarding table check might produce false positives. See + [RFC3704] + + Out-of-Band (OoB) management. + + "Out-of-Band management" is defined as any management done over + channels and interfaces that are separate from those used for + user/customer data. Examples would include a serial console + interface or a network interface connected to a dedicated + management network that is not used to carry customer traffic. + + + + + + + + +Jones Informational [Page 9] + +RFC 3871 Operational Security Requirements September 2004 + + + Open Review. + + "Open review" refers to processes designed to generate public + discussion and review of proposed technical solutions such as data + communications protocols and cryptographic algorithms with the + goals of improving and building confidence in the final solutions. + + For the purposes of this document "open review" is defined by + [RFC2026]. All standards track documents are considered to have + been through an open review process. + + It should be noted that organizations may have local requirements + that define what they view as acceptable "open review". For + example, they may be required to adhere to certain national or + international standards. Such modifications of the definition of + the term "open review", while important, are considered local + issues that should be discussed between the organization and the + vendor. + + It should also be noted that section 7 of [RFC2026] permits + standards track documents to incorporate other "external standards + and specifications". + + Service. + + A number of requirements refer to "services". For the purposes of + this document a "service" is defined as "any process or protocol + running in the control or management planes to which non-transit + packets may be delivered". Examples might include an SSH server, + a BGP process or an NTP server. It would also include the + transport, network and link layer protocols since, for example, a + TCP packet addressed to a port on which no service is listening + will be "delivered" to the IP stack, and possibly result in an + ICMP message being sent back. + + Secure Channel. + + A "secure channel" is a mechanism that ensures end-to-end + integrity and confidentiality of communications. Examples include + TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a + console port using physically secure, shielded cable would provide + confidentiality but possibly not integrity. + + Single-Homed Network. + + A "single-homed network" is defined as one for which + + * There is only one upstream connection + + + +Jones Informational [Page 10] + +RFC 3871 Operational Security Requirements September 2004 + + + * Routing is symmetric. + + See [RFC3704] for a discussion of related issues and mechanisms + for multihomed networks. + + Spoofed Packet. + + A "spoofed packet" is defined as a packet that has a source + address that does not correspond to any address assigned to the + system which sent the packet. Spoofed packets are often "bogons" + or "martians". + +2. Functional Requirements + + The requirements in this section are intended to list testable, + functional requirements that are needed to operate devices securely. + +2.1. Device Management Requirements + +2.1.1. Support Secure Channels For Management + + Requirement. + + The device MUST provide mechanisms to ensure end-to-end integrity + and confidentiality for all network traffic and protocols used to + support management functions. This MUST include at least + protocols used for configuration, monitoring, configuration backup + and restore, logging, time synchronization, authentication, and + routing. + + Justification. + + Integrity protection is required to ensure that unauthorized users + cannot manage the device or alter log data or the results of + management commands. Confidentiality is required so that + unauthorized users cannot view sensitive information, such as + keys, passwords, or the identity of users. + + Examples. + + See [RFC3631] for a current list of mechanisms that can be used to + support secure management. + + Later sections list requirements for supporting in-band management + (Section 2.2) and out-of-band management (Section 2.3) as well as + trade-offs that must be weighed in considering which is + appropriate to a given situation. + + + + +Jones Informational [Page 11] + +RFC 3871 Operational Security Requirements September 2004 + + + Warnings. + + None. + +2.2. In-Band Management Requirements + + This section lists security requirements that support secure in-band + management. In-band management has the advantage of lower cost (no + extra interfaces or lines), but has significant security + disadvantages: + + o Saturation of customer lines or interfaces can make the device + unmanageable unless out-of-band management resources have been + reserved. + + o Since public interfaces/channels are used, it is possible for + attackers to directly address and reach the device and to attempt + management functions. + + o In-band management traffic on public interfaces may be + intercepted, however this would typically require a significant + compromise in the routing system. + + o Public interfaces used for in-band management may become + unavailable due to bugs (e.g., buffer overflows being exploited) + while out-of-band interfaces (such as a serial console device) + remain available. + + There are many situations where in-band management makes sense, is + used, and/or is the only option. The following requirements are + meant to provide means of securing in-band management traffic. + +2.2.1. Use Cryptographic Algorithms Subject To Open Review + + Requirement. + + If cryptography is used to provide secure management functions, + then there MUST be an option to use algorithms that are subject to + "open review" as defined in Section 1.8 to provide these + functions. These SHOULD be used by default. The device MAY + optionally support algorithms that are not open to review. + + Justification. + + Cryptographic algorithms that have not been subjected to + widespread, extended public/peer review are more likely to have + undiscovered weaknesses or flaws than open standards and publicly + reviewed algorithms. Network operators may have need or desire to + + + +Jones Informational [Page 12] + +RFC 3871 Operational Security Requirements September 2004 + + + use non-open cryptographic algorithms. They should be allowed to + evaluate the trade-offs and make an informed choice between open + and non-open cryptography. See [Schneier] for further discussion. + + Examples. + + The following are some algorithms that satisfy the requirement at + the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] + for applications requiring symmetric encryption; RSA [RFC3447] and + Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring + key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications + requiring message verification. + + Warnings. + + This list is not exhaustive. Other strong, well-reviewed + algorithms may meet the requirement. The dynamic nature of the + field means that what is good enough today may not be in the + future. + + Open review is necessary but not sufficient. The strength of the + algorithm and key length must also be considered. For example, + 56-bit DES meets the open review requirement, but is today + considered too weak and is therefore not recommended. + +2.2.2. Use Strong Cryptography + + Requirement. + + If cryptography is used to meet the secure management channel + requirements, then the key lengths and algorithms SHOULD be + "strong". + + Justification. + + Short keys and weak algorithms threaten the confidentiality and + integrity of communications. + + Examples. + + The following algorithms satisfy the requirement at the time of + writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] for + applications requiring symmetric encryption; RSA [RFC3447] and + Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring + key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications + requiring message verification. + + + + + +Jones Informational [Page 13] + +RFC 3871 Operational Security Requirements September 2004 + + + Note that for *new protocols* [RFC3631] says the following: + "Simple keyed hashes based on MD5 [RFC1321], such as that used in + the BGP session security mechanism [RFC2385], are especially to be + avoided in new protocols, given the hints of weakness in MD5." + While use of such hashes in deployed products and protocols is + preferable to a complete lack of integrity and authentication + checks, this document concurs with the recommendation that new + products and protocols strongly consider alternatives. + + Warnings. + + This list is not exhaustive. Other strong, well-reviewed + algorithms may meet the requirement. The dynamic nature of the + field means that what is good enough today may not be in the + future. + + Strength is relative. Long keys and strong algorithms are + intended to increase the work factor required to compromise the + security of the data protected. Over time, as processing power + increases, the security provided by a given algorithm and key + length will degrade. The definition of "Strong" must be + constantly reevaluated. + + There may be legal issues governing the use of cryptography and + the strength of cryptography used. + + This document explicitly does not attempt to make any + authoritative statement about what key lengths constitute "strong" + cryptography. See [RFC3562] and [RFC3766] for help in + determining appropriate key lengths. Also see [Schneier] chapter + 7 for a discussion of key lengths. + +2.2.3. Use Protocols Subject To Open Review For Management + + Requirement. + + If cryptography is used to provide secure management channels, + then its use MUST be supported in protocols that are subject to + "open review" as defined in Section 1.8. These SHOULD be used by + default. The device MAY optionally support the use of + cryptography in protocols that are not open to review. + + + + + + + + + + +Jones Informational [Page 14] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + Protocols that have not been subjected to widespread, extended + public/peer review are more likely to have undiscovered weaknesses + or flaws than open standards and publicly reviewed protocols + Network operators may have need or desire to use non-open + protocols They should be allowed to evaluate the trade-offs and + make an informed choice between open and non-open protocols. + + Examples. + + See TLS [RFC2246] and IPsec [RFC2401]. + + Warnings. + + Note that open review is necessary but may not be sufficient. It + is perfectly possible for an openly reviewed protocol to misuse + (or not use) cryptography. + +2.2.4. Allow Selection of Cryptographic Parameters + + Requirement. + + The device SHOULD allow the operator to select cryptographic + parameters. This SHOULD include key lengths and algorithms. + + Justification. + + Cryptography using certain algorithms and key lengths may be + considered "strong" at one point in time, but "weak" at another. + The constant increase in compute power continually reduces the + time needed to break cryptography of a certain strength. + Weaknesses may be discovered in algorithms. The ability to select + a different algorithm is a useful tool for maintaining security in + the face of such discoveries. + + Examples. + + 56-bit DES was once considered secure. In 1998 it was cracked by + custom built machine in under 3 days. The ability to select + algorithms and key lengths would give the operator options + (different algorithms, longer keys) in the face of such + developments. + + Warnings. + + None. + + + + +Jones Informational [Page 15] + +RFC 3871 Operational Security Requirements September 2004 + + +2.2.5. Management Functions Should Have Increased Priority + + Requirement. + + Management functions SHOULD be processed at higher priority than + non-management traffic. This SHOULD include ingress, egress, + internal transmission, and processing. This SHOULD include at + least protocols used for configuration, monitoring, configuration + backup, logging, time synchronization, authentication, and + routing. + + Justification. + + Certain attacks (and normal operation) can cause resource + saturation such as link congestion, memory exhaustion or CPU + overload. In these cases it is important that management + functions be prioritized to ensure that operators have the tools + needed to recover from the attack. + + Examples. + + Imagine a service provider with 1,000,000 DSL subscribers, most of + whom have no firewall protection. Imagine that a large portion of + these subscribers machines were infected with a new worm that + enabled them to be used in coordinated fashion as part of large + denial of service attack that involved flooding. It is entirely + possible that without prioritization such an attack would cause + link congestion resulting in routing adjacencies being lost. A + DoS attack against hosts has just become a DoS attack against the + network. + + Warnings. + + Prioritization is not a panacea. Routing update packets may not + make it across a saturated link. This requirement simply says + that the device should prioritize management functions within its + scope of control (e.g., ingress, egress, internal transit, + processing). To the extent that this is done across an entire + network, the overall effect will be to ensure that the network + remains manageable. + +2.3. Out-of-Band (OoB) Management Requirements + + See Section 2.2 for a discussion of the advantages and disadvantages + of In-band vs. Out-of-Band management. + + + + + + +Jones Informational [Page 16] + +RFC 3871 Operational Security Requirements September 2004 + + + These requirements assume two different possible Out-of-Band + topologies: + + o serial line (or equivalent) console connections using a CLI, + + o network interfaces connected to a separate network dedicated to + management. + + The following assumptions are made about out-of-band management: + + o The out-of-band management network is secure. + + o Communications beyond the management interface (e.g., console + port, management network interface) is secure. + + o There is no need for encryption of communication on out-of-band + management interfaces, (e.g., on a serial connection between a + terminal server and a device's console port). + + o Security measures are in place to prevent unauthorized physical + access. + + Even if these assumptions hold it would be wise, as an application of + defense-in-depth, to apply the in-band requirements (e.g., + encryption) to out-of-band interfaces. + +2.3.1. Support a 'Console' Interface + + Requirement. + + The device MUST support complete configuration and management via + a 'console' interface that functions independently from the + forwarding and IP control planes. + + Justification. + + There are times when it is operationally necessary to be able to + immediately and easily access a device for management or + configuration, even when the network is unavailable, routing and + network interfaces are incorrectly configured, the IP stack and/or + operating system may not be working (or may be vulnerable to + recently discovered exploits that make their use impossible/ + inadvisable), or when high bandwidth paths to the device are + unavailable. In such situations, a console interface can provide + a way to manage and configure the device. + + + + + + +Jones Informational [Page 17] + +RFC 3871 Operational Security Requirements September 2004 + + + Examples. + + An RS232 (EIA232) interface that provides the capability to load + new versions of the system software and to perform configuration + via a command line interface. RS232 interfaces are ubiquitous and + well understood. + + A simple embedded device that provides management and + configuration access via an Ethernet or USB interface. + + As of this writing, RS232 is still strongly recommended as it + provides the following benefits: + + * Simplicity. RS232 is far simpler than the alternatives. It is + simply a hardware specification. By contrast an Ethernet based + solution might require an ethernet interface, an operating + system, an IP stack and an HTTP server all to be functioning + and properly configured. + + * Proven. RS232 has more than 30 years of use. + + * Well-Understood. Operators have a great deal of experience + with RS232. + + * Availability. It works even in the presence of network + failure. + + * Ubiquity. It is very widely deployed in mid to high end + network infrastructure. + + * Low-Cost. The cost of adding a RS232 port to a device is + small. + + * CLI-Friendly. An RS232 interface and a CLI are sufficient in + most cases to manage a device. No additional software is + required. + + * Integrated. Operators have many solutions (terminal servers, + etc.) currently deployed to support management via RS232. + + While other interfaces may be supplied, the properties listed + above should be considered. Interfaces not having these + properties may present challenges in terms of ease of use, + integration or adoption. Problems in any of these areas could + have negative security impacts, particularly in situations + where the console must be used to quickly respond to incidents. + + + + + +Jones Informational [Page 18] + +RFC 3871 Operational Security Requirements September 2004 + + + Warnings. + + It is common practice is to connect RS232 ports to terminal + servers that permit networked access for convenience. This + increases the potential security exposure of mechanisms available + only via RS232 ports. For example, a password recovery mechanism + that is available only via RS232 might give a remote hacker to + completely reconfigure a router. While operational procedures are + beyond the scope of this document, it is important to note here + that strong attention should be given to policies, procedures, + access mechanisms and physical security governing access to + console ports. + +2.3.2. 'Console' Communication Profile Must Support Reset + + Requirement. + + There MUST be a method defined and published for returning the + console communication parameters to their default settings. This + method must not require the current settings to be known. + + Justification. + + Having to guess at communications settings can waste time. In a + crisis situation, the operator may need to get on the console of a + device quickly. + + Examples. + + One method might be to send a break on a serial line. + + Warnings. + + None. + +2.3.3. 'Console' Requires Minimal Functionality of Attached Devices + + Requirement. + + The use of the 'console' interface MUST NOT require proprietary + devices, protocol extensions or specific client software. + + + + + + + + + + +Jones Informational [Page 19] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + The purpose of having the console interface is to have a + management interface that can be made to work quickly at all + times. Requiring complex or nonstandard behavior on the part of + attached devices reduces the likelihood that the console will work + without hassles. + + Examples. + + If the console is supplied via an RS232 interface, then it should + function with an attached device that only implements a "dumb" + terminal. Support of "advanced" terminal features/types should be + optional. + + Warnings. + + None. + +2.3.4. 'Console' Supports Fall-back Authentication + + Requirement. + + The 'console' SHOULD support an authentication mechanism which + does not require functional IP or depend on external services. + This authentication mechanism MAY be disabled until a failure of + other preferred mechanisms is detected. + + Justification. + + It does little good to have a console interface on a device if you + cannot get into the device with it when the network is not + working. + + Examples. + + Some devices which use TACACS or RADIUS for authentication will + fall back to a local account if the TACACS or RADIUS server does + not reply to an authentication request. + + Warnings. + + This requirement represents a trade-off between being able to + manage the device (functionality) and security. There are many + ways to implement this which would provide reduced security for + the device, (e.g., a back door for unauthorized access). Local + policy should be consulted to determine if "fail open" or "fail + + + + +Jones Informational [Page 20] + +RFC 3871 Operational Security Requirements September 2004 + + + closed" is the correct stance. The implications of "fail closed" + (e.g., not being able to manage a device) should be fully + considered. + + If the fall-back mechanism is disabled, it is important that the + failure of IP based authentication mechanism be reliably detected + and the fall-back mechanism automatically enabled...otherwise the + operator may be left with no means to authenticate. + +2.3.5. Support Separate Management Plane IP Interfaces + + Requirement. + + The device MAY provide designated network interface(s) that are + used for management plane traffic. + + Justification. + + A separate management plane interface allows management traffic to + be segregated from other traffic (data/forwarding plane, control + plane). This reduces the risk that unauthorized individuals will + be able to observe management traffic and/or compromise the + device. + + This requirement applies in situations where a separate OoB + management network exists. + + Examples. + + Ethernet port dedicated to management and isolated from customer + traffic satisfies this requirement. + + Warnings. + + The use of this type of interface depends on proper functioning of + both the operating system and the IP stack, as well as good, known + configuration at least on the portions of the device dedicated to + management. + +2.3.6. No Forwarding Between Management Plane And Other Interfaces + + Requirement. + + If the device implements separate network interface(s) for the + management plane per Section 2.3.5 then the device MUST NOT + forward traffic between the management plane and non-management + plane interfaces. + + + + +Jones Informational [Page 21] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + This prevents the flow, intentional or unintentional, of + management traffic to/from places that it should not be + originating/terminating (e.g., anything beyond the customer-facing + interfaces). + + Examples. + + Implementing separate forwarding tables for management plane and + non-management plane interfaces that do not propagate routes to + each other satisfies this requirement. + + Warnings. + + None. + +2.4. Configuration and Management Interface Requirements + + This section lists requirements that support secure device + configuration and management methods. In most cases, this currently + involves some sort of command line interface (CLI) and configuration + files. It may be possible to meet these requirements with other + mechanisms, for instance SNMP or a script-able HTML interface that + provides full access to management and configuration functions. In + the future, there may be others (e.g., XML based configuration). + +2.4.1. 'CLI' Provides Access to All Configuration and Management + Functions + + Requirement. + + The Command Line Interface (CLI) or equivalent MUST allow complete + access to all configuration and management functions. The CLI + MUST be supported on the console (see Section 2.3.1) and SHOULD be + supported on all other interfaces used for management. + + Justification. + + The CLI (or equivalent) is needed to provide the ability to do + reliable, fast, direct, local management and monitoring of a + device. It is particularly useful in situations where it is not + possible to manage and monitor the device in-band via "normal" + means (e.g., SSH or SNMP [RFC3410], [RFC3411]) that depend on + functional networking. Such situations often occur during + security incidents such as bandwidth-based denial of service + attacks. + + + + +Jones Informational [Page 22] + +RFC 3871 Operational Security Requirements September 2004 + + + Examples. + + Examples of configuration include setting interface addresses, + defining and applying filters, configuring logging and + authentication, etc. Examples of management functions include + displaying dynamic state information such as CPU load, memory + utilization, packet processing statistics, etc. + + Warnings. + + None. + +2.4.2. 'CLI' Supports Scripting of Configuration + + Requirement. + + The CLI or equivalent MUST support external scripting of + configuration functions. This CLI SHOULD support the same command + set and syntax as that in Section 2.4.1. + + Justification. + + During the handling of security incidents, it is often necessary + to quickly make configuration changes on large numbers of devices. + Doing so manually is error prone and slow. Vendor supplied + management solutions do not always foresee or address the type or + scale of solutions that are required. The ability to script + provides a solution to these problems. + + Examples. + + Example uses of scripting include: tracking an attack across a + large network, updating authentication parameters, updating + logging parameters, updating filters, configuration fetching/ + auditing, etc. Some languages that are currently used for + scripting include expect, Perl and TCL. + + Warnings. + + Some properties of the command language that enhance the ability + to script are: simplicity, regularity and consistency. Some + implementations that would make scripting difficult or impossible + include: "text menu" style interfaces (e.g., "curses" on UNIX) or + a hard-coded GUI interfaces (e.g., a native Windows or Macintosh + GUI application) that communicate using a proprietary or + undocumented protocol not based on a CLI. + + + + + +Jones Informational [Page 23] + +RFC 3871 Operational Security Requirements September 2004 + + +2.4.3. 'CLI' Supports Management Over 'Slow' Links + + Requirement. + + The device MUST support a command line interface (CLI) or + equivalent mechanism that works over low bandwidth connections. + + Justification. + + There are situations where high bandwidth for management is not + available, for example when in-band connections are overloaded during + an attack or when low-bandwidth, out-of-band connections such as + modems must be used. It is often under these conditions that it is + most crucial to be able to perform management and configuration + functions. + + Examples. + + The network is down. The network engineer just disabled routing + by mistake on the sole gateway router in a remote unmanned data + center. The only access to the device is over a modem connected + to a console port. The data center customers are starting to call + the support line. The GUI management interface is redrawing the + screen multiple times...slowly... at 9600bps. + + One mechanism that supports operation over slow links is the + ability to apply filters to the output of CLI commands which have + potentially large output. This may be implemented with something + similar to the UNIX pipe facility and "grep" command. + + For example, + + cat largefile.txt | grep interesting-string + + Another is the ability to "page" through large command output, + e.g., the UNIX "more" command: + + For example, + + cat largefile.txt | more + + Warnings. + + One consequence of this requirement may be that requiring a GUI + interface for management is unacceptable unless it can be shown to + work acceptably over slow links. + + + + + +Jones Informational [Page 24] + +RFC 3871 Operational Security Requirements September 2004 + + +2.4.4. 'CLI' Supports Idle Session Timeout + + Requirement. + + The command line interface (CLI) or equivalent mechanism MUST + support a configurable idle timeout value. + + Justification. + + Network administrators go to lunch. They leave themselves logged + in with administrative privileges. They forget to use screen- + savers with password protection. They do this while at + conferences and in other public places. This behavior presents + opportunity for unauthorized access. Idle timeouts reduce the + window of exposure. + + Examples. + + The CLI may provide a configuration command that allows an idle + timeout to be set. If the operator does not enter commands for + that amount of time, the login session will be automatically + terminated. + + Warnings. + + None. + +2.4.5. Support Software Installation + + Requirement. + + The device MUST provide a means to install new software versions. + It MUST be possible to install new software while the device is + disconnected from all public IP networks. This MUST NOT rely on + previous installation and/or configuration. While new software + MAY be loaded from writable media (disk, flash, etc.), the + capability to load new software MUST depend only on non-writable + media (ROM, etc.). The installation procedures SHOULD support + mechanisms to ensure reliability and integrity of data transfers. + + Justification. + + * Vulnerabilities are often discovered in the base software + (operating systems, etc.) shipped by vendors. Often mitigation of + the risk presented by these vulnerabilities can only be + accomplished by updates to the vendor supplied software (e.g., bug + + + + + +Jones Informational [Page 25] + +RFC 3871 Operational Security Requirements September 2004 + + + fixes, new versions of code, etc.). Without a mechanism to load + new vendor supplied code, it may not be possible to mitigate the + risk posed by these vulnerabilities. + + * It is also conceivable that malicious behavior on the part of + hackers or unintentional behaviors on the part of operators could + cause software on devices to be corrupted or erased. In these + situations, it is necessary to have a means to (re)load software + onto the device to restore correct functioning. + + * It is important to be able to load new software while disconnected + from all public IP networks because the device may be vulnerable + to old attacks before the update is complete. + + * One has to assume that hackers, operators, etc. may erase or + corrupt all writable media (disks, flash, etc.). In such + situations, it is necessary to be able to recover starting with + only non-writable media (e.g., CD-ROM, a true ROM-based monitor). + + * System images may be corrupted in transit (from vendor to + customer, or during the loading process) or in storage (bit rot, + defective media, etc.). Failure to reliably load a new image, for + example after a hacker deletes or corrupts the installed image, + could result in extended loss of availability. + + Examples. + + The device could support booting into a simple ROM-based monitor + that supported a set of commands sufficient to load new operating + system code and configuration data from other devices. The + operating system and configuration might be loaded from: + + RS232. The device could support uploading new code via an RS232 + console port. + + CD-ROM. The device could support installing new code from a + locally attached CD-ROM drive. + + NETWORK. The device could support installing new code via a + network interface, assuming that (a) it is disconnected from all + public networks and (b) the device can boot an OS and IP stack + from some read-only media with sufficient capabilities to load new + code from the network. + + + + + + + + +Jones Informational [Page 26] + +RFC 3871 Operational Security Requirements September 2004 + + + FLASH. The device could support booting from flash memory cards. + + Simple mechanisms currently in use to protect the integrity of + system images and data transfer include image checksums and simple + serial file transfer protocols such as XMODEM and Kermit. + + Warnings. + + None. + +2.4.6. Support Remote Configuration Backup + + Requirement. + + The device MUST provide a means to store the system configuration + to a remote server. The stored configuration MUST have sufficient + information to restore the device to its operational state at the + time the configuration is saved. Stored versions of the + configuration MAY be compressed using an algorithm which is + subject to open review, as long as the fact is clearly identified + and the compression can be disabled. Sensitive information such + as passwords that could be used to compromise the security of the + device MAY be excluded from the saved configuration. + + Justification. + + Archived configurations are essential to enable auditing and + recovery. + + Examples. + + Possible implementations include SCP, SFTP or FTP over a secure + channel. See Section 2.1.1 for requirements related to secure + communication channels for management protocols and data. + + Warnings. + + The security of the remote server is assumed, with appropriate + measures being outside the scope of this document. + +2.4.7. Support Remote Configuration Restore + + Requirement. + + The device MUST provide a means to restore a configuration that + was saved as described in Section 2.4.6. The system MUST be + restored to its operational state at the time the configuration + was saved. + + + +Jones Informational [Page 27] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + Restoration of archived configurations allows quick restoration of + service following an outage (security related as well as from + other causes). + + Examples. + + Configurations may be restored using SCP, SFTP or FTP over a + secure channel. See Section 2.1.1 for requirements related to + secure communication channels for management protocols and data. + + Warnings. + + The security of the remote server is assumed, with appropriate + measures being outside the scope of this document. + + Note that if passwords or other sensitive information are excluded + from the saved copy of the configuration, as allowed by Section + 2.4.6, then the restore may not be complete. The operator may + have to set new passwords or supply other information that was not + saved. + +2.4.8. Support Text Configuration Files + + Requirement. + + The device MUST support display, backup and restore of system + configuration in a simple well defined textual format. The + configuration MUST also be viewable as text on the device itself. + It MUST NOT be necessary to use a proprietary program to view the + configuration. + + Justification. + + Simple, well-defined textual configurations facilitate human + understanding of the operational state of the device, enable off- + line audits, and facilitate automation. Requiring the use of a + proprietary program to access the configuration inhibits these + goals. + + Examples. + + A 7-bit ASCII configuration file that shows the current settings + of the various configuration options would satisfy the + requirement, as would a Unicode configuration or any other + "textual" representation. A structured binary format intended + only for consumption by programs would not be acceptable. + + + +Jones Informational [Page 28] + +RFC 3871 Operational Security Requirements September 2004 + + + Warnings. + + Offline copies of configurations should be well protected as they + often contain sensitive information such as SNMP community + strings, passwords, network blocks, customer information, etc. + + "Well defined" and "textual" are open to interpretation. Clearly + an ASCII configuration file with a regular, documented command + oriented-syntax would meet the definition. These are currently in + wide use. Future options, such as XML based configuration may + meet the requirement. Determining this will require evaluation + against the justifications listed above. + +2.5. IP Stack Requirements + +2.5.1. Ability to Identify All Listening Services + + Requirement. + + The vendor MUST: + + * Provide a means to display all services that are listening for + network traffic directed at the device from any external + source. + + * Display the addresses to which each service is bound. + + * Display the addresses assigned to each interface. + + * Display any and all port(s) on which the service is listing. + + * Include both open standard and vendor proprietary services. + + Justification. + + This information is necessary to enable a thorough assessment of + the security risks associated with the operation of the device + (e.g., "does this protocol allow complete management of the device + without also requiring authentication, authorization, or + accounting?"). The information also assists in determining what + steps should be taken to mitigate risk (e.g., "should I turn this + service off ?") + + + + + + + + + +Jones Informational [Page 29] + +RFC 3871 Operational Security Requirements September 2004 + + + Examples. + + If the device is listening for SNMP traffic from any source + directed to the IP addresses of any of its local interfaces, then + this requirement could be met by the provision of a command which + displays that fact. + + Warnings. + + None. + +2.5.2. Ability to Disable Any and All Services + + Requirement. + + The device MUST provide a means to turn off any "services" (see + Section 1.8). + + Justification. + + The ability to disable services for which there is no operational + need will allow administrators to reduce the overall risk posed to + the device. + + Examples. + + Processes that listen on TCP and UDP ports would be prime examples + of services that it must be possible to disable. + + Warnings. + + None. + +2.5.3. Ability to Control Service Bindings for Listening Services + + Requirement. + + The device MUST provide a means for the user to specify the + bindings used for all listening services. It MUST support binding + to any address or net-block associated with any interface local to + the device. This must include addresses bound to physical or + non-physical (e.g., loopback) interfaces. + + Justification. + + It is a common practice among operators to configure "loopback" + pseudo-interfaces to use as the source and destination of + management traffic. These are preferred to physical interfaces + + + +Jones Informational [Page 30] + +RFC 3871 Operational Security Requirements September 2004 + + + because they provide a stable, routable address. Services bound + to the addresses of physical interface addresses might become + unreachable if the associated hardware goes down, is removed, etc. + + This requirement makes it possible to restrict access to + management services using routing. Management services may be + bound only to the addresses of loopback interfaces. The loopback + interfaces may be addressed out of net-blocks that are only routed + between the managed devices and the authorized management + networks/hosts. This has the effect of making it impossible for + anyone to connect to (or attempt to DoS) management services from + anywhere but the authorized management networks/hosts. + + It also greatly reduces the need for complex filters. It reduces + the number of ports listening, and thus the number of potential + avenues of attack. It ensures that only traffic arriving from + legitimate addresses and/or on designated interfaces can access + services on the device. + + Examples. + + If the device listens for inbound SSH connections, this + requirement means that it should be possible to specify that the + device will only listen to connections destined to specific + addresses (e.g., the address of the loopback interface) or + received on certain interfaces (e.g., an Ethernet interface + designated as the "management" interface). It should be possible + in this example to configure the device such that the SSH is NOT + listening to every address configured on the device. Similar + effects may be achieved with the use of global filters, sometimes + called "receive" or "loopback" ACLs, that filter traffic destined + for the device itself on all interfaces. + + Warnings. + + None. + +2.5.4. Ability to Control Service Source Addresses + + Requirement. + + The device MUST provide a means that allows the user to specify + the source addresses used for all outbound connections or + transmissions originating from the device. It SHOULD be possible + to specify source addresses independently for each type of + outbound connection or transmission. Source addresses MUST be + limited to addresses that are assigned to interfaces (including + loopbacks) local to the device. + + + +Jones Informational [Page 31] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + This allows remote devices receiving connections or transmissions + to use source filtering as one means of authentication. For + example, if SNMP traps were configured to use a known loopback + address as their source, the SNMP workstation receiving the traps + (or a firewall in front of it) could be configured to receive SNMP + packets only from that address. + + Examples. + + The operator may allocate a distinct block of addresses from which + all loopbacks are numbered. NTP and syslog can be configured to + use those loopback addresses as source, while SNMP and BGP may be + configured to use specific physical interface addresses. This + would facilitate filtering based on source address as one way of + rejecting unauthorized attempts to connect to peers/servers. + + Warnings. + + Care should be taken to assure that the addresses chosen are + routable between the sending and receiving devices, (e.g., setting + SSH to use a loopback address of 10.1.1.1 which is not routed + between a router and all intended destinations could cause + problems). + + Note that some protocols, such as SCTP [RFC3309], can use more + than one IP address as the endpoint of a single connection. + + Also note that [RFC3631] lists address-based authentication as an + "insecurity mechanism". Address based authentication should be + replaced or augmented by other mechanisms wherever possible. + +2.5.5. Support Automatic Anti-spoofing for Single-Homed Networks + + Requirement. + + The device MUST provide a means to designate particular interfaces + as servicing "single-homed networks" (see Section 1.8) and MUST + provide an option to automatically drop "spoofed packets" (Section + 1.8) received on such interfaces where application of the current + forwarding table would not route return traffic back through the + same interface. This option MUST work in the presence of dynamic + routing and dynamically assigned addresses. + + + + + + + +Jones Informational [Page 32] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of + [RFC1812], and [RFC2827]. + + Examples. + + This requirement could be satisfied in several ways. It could be + satisfied by the provision of a single command that automatically + generates and applies filters to an interface that implements + anti-spoofing. It could be satisfied by the provision of a + command that causes the return path for packets received to be + checked against the current forwarding tables and dropped if they + would not be forwarded back through the interface on which they + were received. + + See [RFC3704]. + + Warnings. + + This requirement only holds for single-homed networks. Note that + a simple forwarding table check is not sufficient in the more + complex scenarios of multi-homed or multi-attached networks, i.e., + where the traffic may be asymmetric. In these cases, a more + extensive check such as Feasible Path RPF could be very useful. + +2.5.6. Support Automatic Discarding Of Bogons and Martians + + Requirement. + + The device MUST provide a means to automatically drop all "bogons" + (Section 1.8) and "martians" (Section 1.8). This option MUST work + in the presence of dynamic routing and dynamically assigned + addresses. + + Justification. + + These sorts of packets have little (no?) legitimate use and are + used primarily to allow individuals and organization to avoid + identification (and thus accountability) and appear to be most + often used for DoS attacks, email abuse, hacking, etc. In + addition, transiting these packets needlessly consumes resources + and may lead to capacity and performance problems for customers. + + See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of + [RFC1812], and [RFC2827]. + + + + + +Jones Informational [Page 33] + +RFC 3871 Operational Security Requirements September 2004 + + + Examples. + + This requirement could be satisfied by the provision of a command + that causes the return path for packets received to be checked + against the current forwarding tables and dropped if no viable + return path exists. This assumes that steps are taken to assure + that no bogon entries are present in the forwarding tables (for + example filtering routing updates per Section 2.7.5 to reject + advertisements of unassigned addresses). + + See [RFC3704]. + + Warnings. + + This requirement only holds for single-homed networks. Note that + a simple forwarding table check is not sufficient in the more + complex scenarios of multi-homed or multi-attached networks, i.e., + where the traffic may be asymmetric. In these cases, a more + extensive check such as Feasible Path RPF could be very useful. + +2.5.7. Support Counters For Dropped Packets + + Requirement. + + The device MUST provide accurate, per-interface counts of spoofed + packets dropped in accordance with Section 2.5.5 and Section + 2.5.6. + + Justification. + + Counters can help in identifying the source of spoofed traffic. + + Examples. + + An edge router may have several single-homed customers attached. + When an attack using spoofed packets is detected, a quick check of + counters may be able to identify which customer is attempting to + send spoofed traffic. + + Warnings. + + None. + + + + + + + + + +Jones Informational [Page 34] + +RFC 3871 Operational Security Requirements September 2004 + + +2.6. Rate Limiting Requirements + +2.6.1. Support Rate Limiting + + Requirement. + + The device MUST provide the capability to limit the rate at which + it will pass traffic based on protocol, source and destination IP + address or CIDR block, source and destination port, and interface. + Protocols MUST include at least IP, ICMP, UDP, and TCP and SHOULD + include any protocol. + + Justification. + + This requirement provides a means of reducing or eliminating the + impact of certain types of attacks. Also, rate limiting has the + advantage that in some cases it can be turned on a priori, thereby + offering some ability to mitigate the effect of future attacks + prior to any explicit operator reaction to the attacks. + + Examples. + + Assume that a web hosting company provides space in its data- + center to a company that becomes unpopular with a certain element + of network users, who then decide to flood the web server with + inbound ICMP traffic. It would be useful in such a situation to + be able to rate-filter inbound ICMP traffic at the data-center's + border routers. On the other side, assume that a new worm is + released that infects vulnerable database servers such that they + then start spewing traffic on TCP port 1433 aimed at random + destination addresses as fast as the system and network interface + of the infected server is capable. Further assume that a data + center has many vulnerable servers that are infected and + simultaneously sending large amounts of traffic with the result + that all outbound links are saturated. Implementation of this + requirement, would allow the network operator to rate limit + inbound and/or outbound TCP 1433 traffic (possibly to a rate of 0 + packets/bytes per second) to respond to the attack and maintain + service levels for other legitimate customers/traffic. + + Warnings. + + None. + + + + + + + + +Jones Informational [Page 35] + +RFC 3871 Operational Security Requirements September 2004 + + +2.6.2. Support Directional Application Of Rate Limiting Per Interface + + Requirement. + + The device MUST provide support to rate-limit input and/or output + separately on each interface. + + Justification. + + This level of granular control allows appropriately targeted + controls that minimize the impact on third parties. + + Examples. + + If an ICMP flood is directed a single customer on an edge router, + it may be appropriate to rate-limit outbound ICMP only on that + customers interface. + + Warnings. + + None. + +2.6.3. Support Rate Limiting Based on State + + Requirement. + + The device MUST be able to rate limit based on all TCP control + flag bits. The device SHOULD support rate limiting of other + stateful protocols where the normal processing of the protocol + gives the device access to protocol state. + + Justification. + + This allows appropriate response to certain classes of attack. + + Examples. + + For example, for TCP sessions, it should be possible to rate limit + based on the SYN, SYN-ACK, RST, or other bit state. + + Warnings. + + None. + + + + + + + + +Jones Informational [Page 36] + +RFC 3871 Operational Security Requirements September 2004 + + +2.7. Basic Filtering Capabilities + +2.7.1. Ability to Filter Traffic + + Requirement. + + The device MUST provide a means to filter IP packets on any + interface implementing IP. + + Justification. + + Packet filtering is important because it provides a basic means of + implementing policies that specify which traffic is allowed and + which is not. It also provides a basic tool for responding to + malicious traffic. + + Examples. + + Access control lists that allow filtering based on protocol and/or + source/destination address and or source/destination port would be + one example. + + Warnings. + + None. + +2.7.2. Ability to Filter Traffic TO the Device + + Requirement. + + It MUST be possible to apply the filtering mechanism to traffic + that is addressed directly to the device via any of its interfaces + - including loopback interfaces. + + Justification. + + This allows the operator to apply filters that protect the device + itself from attacks and unauthorized access. + + Examples. + + Examples of this might include filters that permit only BGP from + peers and SNMP and SSH from an authorized management segment and + directed to the device itself, while dropping all other traffic + addressed to the device. + + + + + + +Jones Informational [Page 37] + +RFC 3871 Operational Security Requirements September 2004 + + + Warnings. + + None. + +2.7.3. Ability to Filter Traffic THROUGH the Device + + Requirement. + + It MUST be possible to apply the filtering mechanism to traffic + that is being routed (switched) through the device. + + Justification. + + This permits implementation of basic policies on devices that + carry transit traffic (routers, switches, etc.). + + Examples. + + One simple and common way to meet this requirement is to provide + the ability to filter traffic inbound to each interface and/or + outbound from each interface. Ingress filtering as described in + [RFC2827] provides one example of the use of this capability. + + Warnings. + + None. + +2.7.4. Ability to Filter Without Significant Performance Degradation + + Requirement. + + The device MUST provide a means to filter packets without + significant performance degradation. This specifically applies to + stateless packet filtering operating on layer 3 (IP) and layer 4 + (TCP or UDP) headers, as well as normal packet forwarding + information such as incoming and outgoing interfaces. + + The device MUST be able to apply stateless packet filters on ALL + interfaces (up to the maximum number possible) simultaneously and + with multiple filters per interface (e.g., inbound and outbound). + + Justification. + + This enables the implementation of filtering wherever and whenever + needed. To the extent that filtering causes degradation, it may + not be possible to apply filters that implement the appropriate + policies. + + + + +Jones Informational [Page 38] + +RFC 3871 Operational Security Requirements September 2004 + + + Examples. + + Another way of stating the requirement is that filter performance + should not be the limiting factor in device throughput. If a + device is capable of forwarding 30Mb/sec without filtering, then + it should be able to forward the same amount with filtering in + place. + + Warnings. + + The definition of "significant" is subjective. At one end of the + spectrum it might mean "the application of filters may cause the + box to crash". At the other end would be a throughput loss of + less than one percent with tens of thousands of filters applied. + The level of performance degradation that is acceptable will have + to be determined by the operator. + + Repeatable test data showing filter performance impact would be + very useful in evaluating conformance with this requirement. + Tests should include such information as packet size, packet rate, + number of interfaces tested (source/destination), types of + interfaces, routing table size, routing protocols in use, + frequency of routing updates, etc. See [bmwg-acc-bench]. + + This requirement does not address stateful filtering, filtering + above layer 4 headers or other more advanced types of filtering + that may be important in certain operational environments. + +2.7.5. Support Route Filtering + + Requirement. + + The device MUST provide a means to filter routing updates for all + protocols used to exchange external routing information. + + Justification. + + See [RFC3013] and section 3.2 of [RFC2196]. + + Examples. + + Operators may wish to ignore advertisements for routes to + addresses allocated for private internets. See eBGP. + + Warnings. + + None. + + + + +Jones Informational [Page 39] + +RFC 3871 Operational Security Requirements September 2004 + + +2.7.6. Ability to Specify Filter Actions + + Requirement. + + The device MUST provide a mechanism to allow the specification of + the action to be taken when a filter rule matches. Actions MUST + include "permit" (allow the traffic), "reject" (drop with + appropriate notification to sender), and "drop" (drop with no + notification to sender). Also see Section 2.7.7 and Section 2.9 + + Justification. + + This capability is essential to the use of filters to enforce + policy. + + Examples. + + Assume that you have a small DMZ network connected to the + Internet. You want to allow management using SSH coming from your + corporate office. In this case, you might "permit" all traffic to + port 22 in the DMZ from your corporate network, "rejecting" all + others. Port 22 traffic from the corporate network is allowed + through. Port 22 traffic from all other addresses results in an + ICMP message to the sender. For those who are slightly more + paranoid, you might choose to "drop" instead of "reject" traffic + from unauthorized addresses, with the result being that *nothing* + is sent back to the source. + + Warnings. + + While silently dropping traffic without sending notification may + be the correct action in security terms, consideration should be + given to operational implications. See [RFC3360] for + consideration of potential problems caused by sending + inappropriate TCP Resets. + +2.7.7. Ability to Log Filter Actions + + Requirement. + + It MUST be possible to log all filter actions. The logging + capability MUST be able to capture at least the following data: + + * permit/deny/drop status, + + * source and destination IP address, + + * source and destination ports (if applicable to the protocol), + + + +Jones Informational [Page 40] + +RFC 3871 Operational Security Requirements September 2004 + + + * which network element received the packet (interface, MAC + address or other layer 2 information that identifies the + previous hop source of the packet). + + Logging of filter actions is subject to the requirements of + Section 2.11. + + Justification. + + Logging is essential for auditing, incident response, and + operations. + Examples. + + A desktop network may not provide any services that should be + accessible from "outside." In such cases, all inbound connection + attempts should be logged as possible intrusion attempts. + + Warnings. + + None. + +2.8. Packet Filtering Criteria + +2.8.1. Ability to Filter on Protocols + + Requirement. + + The device MUST provide a means to filter traffic based on the + value of the protocol field in the IP header. + + Justification. + + Being able to filter on protocol is necessary to allow + implementation of policy, secure operations and for support of + incident response. + + Examples. + + Some denial of service attacks are based on the ability to flood + the victim with ICMP traffic. One quick way (admittedly with some + negative side effects) to mitigate the effects of such attacks is + to drop all ICMP traffic headed toward the victim. + + Warnings. + + None. + + + + + +Jones Informational [Page 41] + +RFC 3871 Operational Security Requirements September 2004 + + +2.8.2. Ability to Filter on Addresses + + Requirement. + + The function MUST be able to control the flow of traffic based on + source and/or destination IP address or blocks of addresses such + as Classless Inter-Domain Routing (CIDR) blocks. + + Justification. + + The capability to filter on addresses and address blocks is a + fundamental tool for establishing boundaries between different + networks. + + Examples. + + One example of the use of address based filtering is to implement + ingress filtering per [RFC2827]. + + Warnings. + + None. + +2.8.3. Ability to Filter on Protocol Header Fields + + Requirement. + + The filtering mechanism MUST support filtering based on the + value(s) of any portion of the protocol headers for IP, ICMP, UDP + and TCP. It SHOULD support filtering of all other protocols + supported at layer 3 and 4. It MAY support filtering based on the + headers of higher level protocols. It SHOULD be possible to + specify fields by name (e.g., "protocol = ICMP") rather than bit- + offset/length/numeric value (e.g., 72:8 = 1). + + Justification. + + Being able to filter on portions of the header is necessary to + allow implementation of policy, secure operations, and support + incident response. + + Examples. + + This requirement implies that it is possible to filter based on + TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, + and ICMP type and code fields. One common example is to reject + "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear + or SYN bit set+ACK,FIN and RST bits clear). Another common + + + +Jones Informational [Page 42] + +RFC 3871 Operational Security Requirements September 2004 + + + example is the ability to control what services are allowed in/out + of a network. It may be desirable to only allow inbound + connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting + web servers. + + Warnings. + + None. + +2.8.4. Ability to Filter Inbound and Outbound + + Requirement. + + It MUST be possible to filter both incoming and outgoing traffic + on any interface. + + Justification. + + This requirement allows flexibility in applying filters at the + place that makes the most sense. It allows invalid or malicious + traffic to be dropped as close to the source as possible. + + Examples. + + It might be desirable on a border router, for example, to apply an + egress filter outbound on the interface that connects a site to + its external ISP to drop outbound traffic that does not have a + valid internal source address. Inbound, it might be desirable to + apply a filter that blocks all traffic from a site that is known + to forward or originate lots of junk mail. + + Warnings. + + None. + +2.9. Packet Filtering Counter Requirements + +2.9.1. Ability to Accurately Count Filter Hits + + Requirement. + + The device MUST supply a facility for accurately counting all + filter hits. + + + + + + + + +Jones Informational [Page 43] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + Accurate counting of filter rule matches is important because it + shows the frequency of attempts to violate policy. This enables + resources to be focused on areas of greatest need. + + Examples. + + Assume, for example, that a ISP network implements anti-spoofing + egress filters (see [RFC2827]) on interfaces of its edge routers + that support single-homed stub networks. Counters could enable + the ISP to detect cases where large numbers of spoofed packets are + being sent. This may indicate that the customer is performing + potentially malicious actions (possibly in violation of the ISPs + Acceptable Use Policy), or that system(s) on the customers network + have been "owned" by hackers and are being (mis)used to launch + attacks. + + Warnings. + + None. + +2.9.2. Ability to Display Filter Counters + + Requirement. + + The device MUST provide a mechanism to display filter counters. + + Justification. + + Information that is collected is not useful unless it can be + displayed in a useful manner. + + Examples. + + Assume there is a router with four interfaces. One is an up-link + to an ISP providing routes to the Internet. The other three + connect to separate internal networks. Assume that a host on one + of the internal networks has been compromised by a hacker and is + sending traffic with bogus source addresses. In such a situation, + it might be desirable to apply ingress filters to each of the + internal interfaces. Once the filters are in place, the counters + can be examined to determine the source (inbound interface) of the + bogus packets. + + Warnings. + + None. + + + +Jones Informational [Page 44] + +RFC 3871 Operational Security Requirements September 2004 + + +2.9.3. Ability to Display Filter Counters per Rule + + Requirement. + + The device MUST provide a mechanism to display filter counters per + rule. + + Justification. + + This makes it possible to see which rules are matching and how + frequently. + + Examples. + + Assume that a filter has been defined that has two rules, one + permitting all SSH traffic (tcp/22) and the second dropping all + remaining traffic. If three packets are directed toward/through + the point at which the filter is applied, one to port 22, the + others to different ports, then the counter display should show 1 + packet matching the permit tcp/22 rule and 2 packets matching the + deny all others rule. + + Warnings. + + None. + +2.9.4. Ability to Display Filter Counters per Filter Application + + Requirement. + + If it is possible for a filter to be applied more than once at the + same time, then the device MUST provide a mechanism to display + filter counters per filter application. + + Justification. + + It may make sense to apply the same filter definition + simultaneously more than one time (to different interfaces, etc.). + If so, it would be much more useful to know which instance of a + filter is matching than to know that some instance was matching + somewhere. + + Examples. + + One way to implement this requirement would be to have the counter + display mechanism show the interface (or other entity) to which + the filter has been applied, along with the name (or other + designator) for the filter. For example if a filter named + + + +Jones Informational [Page 45] + +RFC 3871 Operational Security Requirements September 2004 + + + "desktop_outbound" applied two different interfaces, say, + "ethernet0" and "ethernet1", the display should indicate something + like "matches of filter 'desktop_outbound' on ethernet0 ..." and + "matches of filter 'desktop_outbound' on ethernet1 ..." + + Warnings. + + None. + +2.9.5. Ability to Reset Filter Counters + + Requirement. + + It MUST be possible to reset counters to zero on a per filter + basis. + + For the purposes of this requirement it would be acceptable for + the system to maintain two counters: an "absolute counter", + C[now], and a "reset" counter, C[reset]. The absolute counter + would maintain counts that increase monotonically until they wrap + or overflow the counter. The reset counter would receive a copy + of the current value of the absolute counter when the reset + function was issued for that counter. Functions that display or + retrieve the counter could then display the delta (C[now] - + C[reset]). + + Justification. + + This allows operators to get a current picture of the traffic + matching particular rules/filters. + + Examples. + + Assume that filter counters are being used to detect internal + hosts that are infected with a new worm. Once it is believed that + all infected hosts have been cleaned up and the worm removed, the + next step would be to verify that. One way of doing so would be + to reset the filter counters to zero and see if traffic indicative + of the worm has ceased. + + Warnings. + + None. + + + + + + + + +Jones Informational [Page 46] + +RFC 3871 Operational Security Requirements September 2004 + + +2.9.6. Filter Counters Must Be Accurate + + Requirement. + + Filter counters MUST be accurate. They MUST reflect the actual + number of matching packets since the last counter reset. Filter + counters MUST be capable of holding up to 2^32 - 1 values without + overflowing and SHOULD be capable of holding up to 2^64 - 1 + values. + + Justification. + + Inaccurate data can not be relied on as the basis for action. + Underreported data can conceal the magnitude of a problem. + + Examples. + + If N packets matching a filter are sent to/through a device, then + the counter should show N matches. + + Warnings. + + None. + +2.10. Other Packet Filtering Requirements + +2.10.1. Ability to Specify Filter Log Granularity + + Requirement. + + It MUST be possible to enable/disable logging on a per rule basis. + + Justification. + + The ability to tune the granularity of logging allows the operator + to log only the information that is desired. Without this + capability, it is possible that extra data (or none at all) would + be logged, making it more difficult to find relevant information. + + Examples. + + If a filter is defined that has several rules, and one of the + rules denies telnet (tcp/23) connections, then it should be + possible to specify that only matches on the rule that denies + telnet should generate a log message. + + + + + + +Jones Informational [Page 47] + +RFC 3871 Operational Security Requirements September 2004 + + + Warnings. + + None. + +2.11. Event Logging Requirements + +2.11.1. Logging Facility Uses Protocols Subject To Open Review + + Requirement. + + The device MUST provide a logging facility that is based on + protocols subject to open review. See Section 1.8. Custom or + proprietary logging protocols MAY be implemented provided the same + information is made available. + + Justification. + + The use of logging based on protocols subject to open review + permits the operator to perform archival and analysis of logs + without relying on vendor-supplied software and servers. + + Examples. + + This requirement may be satisfied by the use of one or more of + syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ + [RFC1492] or RADIUS [RFC2865]. + + Warnings. + + While [RFC3164] meets this requirement, it has many security + issues and by itself does not meet the requirements of Section + 2.1.1. See the security considerations section of [RFC3164] for + a list of issues. [RFC3195] provides solutions to most/all of + these issues....however at the time of this writing there are few + implementations. Other possible solutions might be to tunnel + syslog over a secure transport...but this often raises difficult + key management and scalability issues. + + The current best solution seems to be the following: + + * Implement [RFC3164]. + + * Consider implementing [RFC3195]. + + + + + + + + +Jones Informational [Page 48] + +RFC 3871 Operational Security Requirements September 2004 + + +2.11.2. Logs Sent To Remote Servers + + Requirement. + + The device MUST support transmission of records of security + related events to one or more remote devices. There MUST be + configuration settings on the device that allow selection of + servers. + + Justification. + + This is important because it supports individual accountability. + It is important to store them on a separate server to preserve + them in case of failure or compromise of the managed device. + + Examples. + + This requirement may be satisfied by the use of one or more of: + syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ + [RFC1492] or RADIUS [RFC2865]. + + Warnings. + + Note that there may be privacy or legal considerations when + logging/monitoring user activity. + + High volumes of logging may generate excessive network traffic + and/or compete for scarce memory and CPU resources on the device. + +2.11.3. Ability to Select Reliable Delivery + + Requirement. + + It SHOULD be possible to select reliable delivery of log messages. + + Justification. + + Reliable delivery is important to the extent that log data is + depended upon to make operational decisions and forensic analysis. + Without reliable delivery, log data becomes a collection of hints. + + Examples. + + One example of reliable syslog delivery is defined in [RFC3195]. + Syslog-ng provides another example, although the protocol has not + been standardized. + + + + + +Jones Informational [Page 49] + +RFC 3871 Operational Security Requirements September 2004 + + + Warnings. + + None. + +2.11.4. Ability to Log Locally + + Requirement. + + It SHOULD be possible to log locally on the device itself. Local + logging SHOULD be written to non-volatile storage. + + Justification. + + Local logging of failed authentication attempts to non-volatile + storage is critical. It provides a means of detecting attacks + where the device is isolated from its authentication interfaces + and attacked at the console. + + Local logging is important for viewing information when connected + to the device. It provides some backup of log data in case remote + logging fails. It provides a way to view logs relevant to one + device without having to sort through a possibly large set of logs + from other devices. + + Examples. + + One example of local logging would be a memory buffer that + receives copies of messages sent to the remote log server. + Another example might be a local syslog server (assuming the + device is capable of running syslog and has some local storage). + + Warnings. + + Storage on the device may be limited. High volumes of logging may + quickly fill available storage, in which case there are two + options: new logs overwrite old logs (possibly via the use of a + circular memory buffer or log file rotation), or logging stops. + +2.11.5. Ability to Maintain Accurate System Time + + Requirement. + + The device MUST maintain accurate, "high resolution" (see + definition in Section 1.8) system time. + + + + + + + +Jones Informational [Page 50] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + Accurate time is important to the generation of reliable log data. + Accurate time is also important to the correct operation of some + authentication mechanisms. + + Examples. + + This requirement may be satisfied by supporting Network Time + Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct + connection to an accurate time source. + + Warnings. + + System clock chips are inaccurate to varying degrees. System time + should not be relied upon unless it is regularly checked and + synchronized with a known, accurate external time source (such as + an NTP stratum-1 server). Also note that if network time + synchronization is used, an attacker may be able to manipulate the + clock unless cryptographic authentication is used. + +2.11.6. Display Timezone And UTC Offset + + Requirement. + + All displays and logs of system time MUST include a timezone or + offset from UTC. + + Justification. + + Knowing the timezone or UTC offset makes correlation of data and + coordination with data in other timezones possible. + + Examples. + + Bob is in Newfoundland, Canada which is UTC -3:30. Alice is + somewhere in Indiana, USA. Some parts of Indiana switch to + daylight savings time while others do not. A user on Bob's + network attacks a user on Alice's network. Both are using logs + with local timezones and no indication of UTC offset. Correlating + these logs will be difficult and error prone. Including timezone, + or better, UTC offset, eliminates these difficulties. + + Warnings. + + None. + + + + + +Jones Informational [Page 51] + +RFC 3871 Operational Security Requirements September 2004 + + +2.11.7. Default Timezone Should Be UTC + + Requirement. + + The default timezone for display and logging SHOULD be UTC. The + device MAY support a mechanism to allow the operator to specify + the display and logging of times in a timezone other than UTC. + + Justification. + + Knowing the timezone or UTC offset makes correlation of data and + coordination with data in other timezones possible. + + Examples. + + Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or + UTC -6 depending on the time of year and exact county in Indiana) + are working an incident together using their logs. Both left the + default settings, which was UTC, so there was no translation of + time necessary to correlate the logs. + + Warnings. + + None. + +2.11.8. Logs Must Be Timestamped + + Requirement. + + By default, the device MUST timestamp all log messages. The + timestamp MUST be accurate to within a second or less. The + timestamp MUST include a timezone. There MAY be a mechanism to + disable the generation of timestamps. + + Justification. + + Accurate timestamps are necessary for correlating events, + particularly across multiple devices or with other organizations. + This applies when it is necessary to analyze logs. + + Examples. + + This requirement MAY be satisfied by writing timestamps into + syslog messages. + + + + + + + +Jones Informational [Page 52] + +RFC 3871 Operational Security Requirements September 2004 + + + Warnings. + + It is difficult to correlate logs from different time zones. + Security events on the Internet often involve machines and logs + from a variety of physical locations. For that reason, UTC is + preferred, all other things being equal. + +2.11.9. Logs Contain Untranslated IP Addresses + + Requirement. + + Log messages MUST NOT list translated addresses (DNS names) + associated with the address without listing the untranslated IP + address where the IP address is available to the device generating + the log message. + + Justification. + + Including IP address of access list violations authentication + attempts, address lease assignments and similar events in logs + enables a level of individual and organizational accountability + and is necessary to enable analysis of network events, incidents, + policy violations, etc. + + DNS entries tend to change more quickly than IP block assignments. + This makes the address more reliable for data forensics. + + DNS lookups can be slow and consume resources. + + Examples. + + A failed network login should generate a record with the source + address of the login attempt. + + Warnings. + + * Source addresses may be spoofed. Network-based attacks often + use spoofed source addresses. Source addresses should not be + completely trusted unless verified by other means. + + * Addresses may be reassigned to different individual, for + example, in a desktop environment using DHCP. In such cases + the individual accountability afforded by this requirement is + weak. Having accurate time in the logs increases the chances + that the use of an address can be correlated to an individual. + + + + + + +Jones Informational [Page 53] + +RFC 3871 Operational Security Requirements September 2004 + + + * Network topologies may change. Even in the absence of dynamic + address assignment, network topologies and address block + assignments do change. Logs of an attack one month ago may not + give an accurate indication of which host, network or + organization owned the system(s) in question at the time. + +2.11.10. Logs Contain Records Of Security Events + + Requirement. + + The device MUST be able to send a record of at least the following + events: + + * authentication successes, + + * authentication failures, + + * session Termination, + + * authorization changes, + + * configuration changes, + + * device status changes. + + The device SHOULD be able to send a record of all other security + related events. + + Justification. + + This is important because it supports individual accountability. + See section 4.5.4.4 of [RFC2196]. + + Examples. + + Examples of events for which there must be a record include: user + logins, bad login attempts, logouts, user privilege level changes, + individual configuration commands issued by users and system + startup/shutdown events. + + Warnings. + + This list is far from complete. + + Note that there may be privacy or legal considerations when + logging/monitoring user activity. + + + + + +Jones Informational [Page 54] + +RFC 3871 Operational Security Requirements September 2004 + + +2.11.11. Logs Do Not Contain Passwords + + Requirement. + + Passwords SHOULD be excluded from all audit records, including + records of successful or failed authentication attempts. + + Justification. + + Access control and authorization requirements differ for + accounting records (logs) and authorization databases (passwords). + Logging passwords may grant unauthorized access to individuals + with access to the logs. Logging failed passwords may give hints + about actual passwords. See section 4.5.4.4 of [RFC2196]. + + Examples. + + A user may make small mistakes in entering a password such as + using incorrect capitalization ("my password" vs. "My Password"). + + Warnings. + + There may be situations where it is appropriate/required to log + passwords. + +2.12. Authentication, Authorization, and Accounting (AAA) Requirements + +2.12.1. Authenticate All User Access + + Requirement. + + The device MUST provide a facility to perform authentication of + all user access to the system. + + Justification. + + This functionality is required so that access to the system can be + restricted to authorized personnel. + + Examples. + + This requirement MAY be satisfied by implementing a centralized + authentication system. See Section 2.12.5. It MAY also be + satisfied using local authentication. See Section 2.12.6. + + Warnings. + + None. + + + +Jones Informational [Page 55] + +RFC 3871 Operational Security Requirements September 2004 + + +2.12.2. Support Authentication of Individual Users + + Requirement. + + Mechanisms used to authenticate interactive access for + configuration and management MUST support the authentication of + distinct, individual users. This requirement MAY be relaxed to + support system installation Section 2.4.5 or recovery of + authorized access Section 2.12.15. + + Justification. + + The use of individual accounts, in conjunction with logging, + promotes accountability. The use of group or default accounts + undermines individual accountability. + + Examples. + + A user may need to log in to the device to access CLI functions + for management. Individual user authentication could be provided + by a centralized authentication server or a username/password + database stored on the device. It would be a violation of this + rule for the device to only support a single "account" (with or + without a username) and a single password shared by all users to + gain administrative access. + + Warnings. + + This simply requires that the mechanism to support individual + users be present. Policy (e.g., forbidding shared group accounts) + and enforcement are also needed but beyond the scope of this + document. + +2.12.3. Support Simultaneous Connections + + Requirement. + + The device MUST support multiple simultaneous connections by + distinct users, possibly at different authorization levels. + + Justification. + + This allows multiple people to perform authorized management + functions simultaneously. This also means that attempted + connections by unauthorized users do not automatically lock out + authorized users. + + + + + +Jones Informational [Page 56] + +RFC 3871 Operational Security Requirements September 2004 + + + Examples. + + None. + + Warnings. + + None. + +2.12.4. Ability to Disable All Local Accounts + + Requirement. + + The device MUST provide a means of disabling all local accounts + including: + + * local users, + + * default accounts (vendor, maintenance, guest, etc.), + + * privileged and unprivileged accounts. + + A local account defined as one where all information necessary for + user authentication is stored on the device. + + Justification. + + Default accounts, well-known accounts, and old accounts provide + easy targets for someone attempting to gain access to a device. + It must be possible to disable them to reduce the potential + vulnerability. + + Examples. + + The implementation depends on the types of authentication + supported by the device. + + Warnings. + + None. + +2.12.5. Support Centralized User Authentication Methods + + Requirement. + + The device MUST support a method of centralized authentication of + all user access via standard authentication protocols. + + + + + +Jones Informational [Page 57] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + Support for centralized authentication is particularly important + in large environments where the network devices are widely + distributed and where many people have access to them. This + reduces the effort needed to effectively restrict and track access + to the system by authorized personnel. + + Examples. + + This requirement can be satisfied through the use of DIAMETER + [RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos + [RFC1510]. + + The secure management requirements (Section 2.1.1) apply to AAA. + + See [RFC3579] for a discussion security issues related to RADIUS. + + Warnings. + + None. + +2.12.6. Support Local User Authentication Method + + Requirement. + + The device SHOULD support a local authentication method. If + implemented, the method MUST NOT require interaction with anything + external to the device (such as remote AAA servers), and MUST + work in conjunction with Section 2.3.1 (Support a 'Console' + Interface) and Section 2.12.7 (Support Configuration of Order of + Authentication Methods). + + Justification. + + Support for local authentication may be required in smaller + environments where there may be only a few devices and a limited + number of people with access. The overhead of maintaining + centralized authentication servers may not be justified. + + Examples. + + The use of local, per-device usernames and passwords provides one + way to implement this requirement. + + + + + + + +Jones Informational [Page 58] + +RFC 3871 Operational Security Requirements September 2004 + + + Warnings. + + Authentication information must be protected wherever it resides. + Having, for instance, local usernames and passwords stored on 100 + network devices means that there are 100 potential points of + failure where the information could be compromised vs. storing + authentication data centralized server(s), which would reduce the + potential points of failure to the number of servers and allow + protection efforts (system hardening, audits, etc.) to be focused + on, at most, a few servers. + +2.12.7. Support Configuration of Order of Authentication Methods + + Requirement. + + The device MUST support the ability to configure the order in + which supported authentication methods are attempted. + Authentication SHOULD "fail closed", i.e., access should be denied + if none of the listed authentication methods succeeds. + + Justification. + + This allows the operator flexibility in implementing appropriate + security policies that balance operational and security needs. + + Examples. + + If, for example, a device supports RADIUS authentication and local + usernames and passwords, it should be possible to specify that + RADIUS authentication should be attempted if the servers are + available, and that local usernames and passwords should be used + for authentication only if the RADIUS servers are not available. + Similarly, it should be possible to specify that only RADIUS or + only local authentication be used. + + Warnings. + + None. + +2.12.8. Ability To Authenticate Without Plaintext Passwords + + Requirement. + + The device MUST support mechanisms that do not require the + transmission of plaintext passwords in all cases that require the + transmission of authentication information across networks. + + + + + +Jones Informational [Page 59] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + Plaintext passwords can be easily observed using packet sniffers + on shared networks. See [RFC1704] and [RFC3631] for a through + discussion. + + Examples. + + Remote login requires the transmission of authentication + information across networks. Telnet transmits plaintext + passwords. SSH does not. Telnet fails this requirement. SSH + passes. + + Warnings. + + None. + +2.12.9. No Default Passwords + + Requirement. + + The initial configuration of the device MUST NOT contain any + default passwords or other authentication tokens. + + Justification. + + Default passwords provide an easy way for attackers to gain + unauthorized access to the device. + + Examples. + + Passwords such as the name of the vendor, device, "default", etc. + are easily guessed. The SNMP community strings "public" and + "private" are well known defaults that provide read and write + access to devices. + + Warnings. + + Lists of default passwords for various devices are readily + available at numerous websites. + +2.12.10. Passwords Must Be Explicitly Configured Prior To Use + + Requirement. + + The device MUST require the operator to explicitly configure + "passwords" prior to use. + + + + +Jones Informational [Page 60] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + This requirement is intended to prevent unauthorized management + access. Requiring the operator to explicitly configure passwords + will tend to have the effect of ensuring a diversity of passwords. + It also shifts the responsibility for password selection to the + user. + + Examples. + + Assume that a device comes with console port for management and a + default administrative account. This requirement together with No + Default Passwords says that the administrative account should come + with no password configured. One way of meeting this requirement + would be to have the device require the operator to choose a + password for the administrative account as part of a dialog the + first time the device is configured. + + Warnings. + + While this device requires operators to set passwords, it does not + prevent them from doing things such as using scripts to configure + hundreds of devices with the same easily guessed passwords. + +2.12.11. Ability to Define Privilege Levels + + Requirement. + + It MUST be possible to define arbitrary subsets of all management + and configuration functions and assign them to groups or + "privilege levels", which can be assigned to users per Section + 2.12.12. There MUST be at least three possible privilege levels. + + Justification. + + This requirement supports the implementation of the principal of + "least privilege", which states that an individual should only + have the privileges necessary to execute the operations he/she is + required to perform. + + Examples. + + Examples of privilege levels might include "user" which only + allows the initiation of a PPP or telnet session, "read only", + which allows read-only access to device configuration and + operational statistics, "root/superuser/administrator" which + allows update access to all configurable parameters, and + "operator" which allows updates to a limited, user defined set of + + + +Jones Informational [Page 61] + +RFC 3871 Operational Security Requirements September 2004 + + + parameters. Note that privilege levels may be defined locally on + the device or on centralized authentication servers. + + Warnings. + + None. + +2.12.12. Ability to Assign Privilege Levels to Users + + Requirement. + + The device MUST be able to assign a defined set of authorized + functions, or "privilege level", to each user once they have + authenticated themselves to the device. Privilege level + determines which functions a user is allowed to execute. Also see + Section 2.12.11. + + Justification. + + This requirement supports the implementation of the principal of + "least privilege", which states that an individual should only + have the privileges necessary to execute the operations he/she is + required to perform. + + Examples. + + The implementation of this requirement will obviously be closely + coupled with the authentication mechanism. If RADIUS is used, an + attribute could be set in the user's RADIUS profile that can be + used to map the ID to a certain privilege level. + + Warnings. + + None. + +2.12.13. Default Privilege Level Must Be 'None' + + Requirement. + + The default privilege level SHOULD NOT allow any access to + management or configuration functions. It MAY allow access to + user-level functions (e.g., starting PPP or telnet). It SHOULD be + possible to assign a different privilege level as the default. + This requirement MAY be relaxed to support system installation per + Section 2.4.5 or recovery of authorized access per Section + 2.12.15. + + + + + +Jones Informational [Page 62] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + This requirement supports the implementation of the principal of + "least privilege", which states that an individual should only + have the privileges necessary to execute the operations he/she is + required to perform. + + Examples. + + Examples of privilege levels might include "user" which only + allows the initiation of a PPP or telnet session, "read-only", + which allows read-only access to device configuration and + operational statistics, "root/superuser/administrator" which + allows update access to all configurable parameters, and + "operator" which allows updates to a limited, user defined set of + parameters. Note that privilege levels may be defined locally on + the device or on centralized authentication servers. + + Warnings. + + It may be required to provide exceptions to support the + requirements to support recovery of privileged access (Section + 2.12.15) and to support OS installation and configuration (Section + 2.4.5). For example, if the OS and/or configuration has somehow + become corrupt an authorized individual with physical access may + need to have "root" level access to perform an install. + +2.12.14. Change in Privilege Levels Requires Re-Authentication + + Requirement. + + The device MUST re-authenticate a user prior to granting any + change in user authorizations. + + Justification. + + This requirement ensures that users are able to perform only + authorized actions. + + Examples. + + This requirement might be implemented by assigning base privilege + levels to all users and allowing the user to request additional + privileges, with the requests validated by the AAA server. + + Warnings. + + None. + + + +Jones Informational [Page 63] + +RFC 3871 Operational Security Requirements September 2004 + + +2.12.15. Support Recovery Of Privileged Access + + Requirement. + + The device MUST support a mechanism to allow authorized + individuals to recover full privileged administrative access in + the event that access is lost. Use of the mechanism MUST require + physical access to the device. There MAY be a mechanism for + disabling the recovery feature. + + Justification. + + There are times when local administrative passwords are forgotten, + when the only person who knows them leaves the company, or when + hackers set or change the password. In all these cases, + legitimate administrative access to the device is lost. There + should be a way to recover access. Requiring physical access to + invoke the procedure makes it less likely that it will be abused. + Some organizations may want an even higher level of security and + be willing to risk total loss of authorized access by disabling + the recovery feature, even for those with physical access. + + Examples. + + Some examples of ways to satisfy this requirement are to have the + device give the user the chance to set a new administrative + password when: + + * The user sets a jumper on the system board to a particular + position. + + * The user sends a special sequence to the RS232 console port + during the initial boot sequence. + + * The user sets a "boot register" to a particular value. + + Warnings. + + This mechanism, by design, provides a "back door" to complete + administrative control of the device and may not be appropriate + for environments where those with physical access to the device + can not be trusted. + + Also see the warnings in Section 2.3.1 (Support a 'Console' + Interface). + + + + + + +Jones Informational [Page 64] + +RFC 3871 Operational Security Requirements September 2004 + + +2.13. Layer 2 Devices Must Meet Higher Layer Requirements + + Requirement. + + If a device provides layer 2 services that are dependent on layer + 3 or greater services, then the portions that operate at or above + layer 3 MUST conform to the requirements listed in this document. + + Justification. + + All layer 3 devices have similar security needs and should be + subject to similar requirements. + + Examples. + + Signaling protocols required for layer 2 switching may exchange + information with other devices using layer 3 communications. In + such cases, the device must provide a secure layer 3 facility. + Also, if higher layer capabilities (say, SSH or SNMP) are used to + manage a layer 2 device, then the rest of the requirements in this + document apply to those capabilities. + + Warnings. + + None. + +2.14. Security Features Must Not Cause Operational Problems + + Requirement. + + The use of security features specified by the requirements in this + document SHOULD NOT cause severe operational problems. + + Justification. + + Security features which cause operational problems are not useful + and may leave the operator with no mechanism for enforcing + appropriate policy. + + Examples. + + Some examples of severe operational problems include: + + * The device crashes. + + * The device becomes unmanageable. + + * Data is lost. + + + +Jones Informational [Page 65] + +RFC 3871 Operational Security Requirements September 2004 + + + * Use of the security feature consumes excessive resources (CPU, + memory, bandwidth). + + Warnings. + + Determination of compliance with this requirement involves a level + of judgement. What is "severe"? Certainly crashing is severe, + but what about a %5 loss in throughput when logging is enabled? + It should also be noted that there may be unavoidable physical + limitations such as the total capacity of a link. + +2.15. Security Features Should Have Minimal Performance Impact + + Requirement. + + Security features specified by the requirements in this document + SHOULD be implemented with minimal impact on performance. Other + sections of this document may specify different performance + requirements (e.g., "MUST"s). + + Justification. + + Security features which significantly impact performance may leave + the operator with no mechanism for enforcing appropriate policy. + + Examples. + + If the application of filters is known to have the potential to + significantly reduce throughput for non-filtered traffic, there + will be a tendency, or in some cases a policy, not to use filters. + + Assume, for example, that a new worm is released that scans random + IP addresses looking for services listening on TCP port 1433. An + operator might want to investigate to see if any of the hosts on + their networks were infected and trying to spread the worm. One + way to do this would be to put up non-blocking filters counting + and logging the number of outbound connection 1433, and then to + block the requests that are determined to be from infected hosts. + If any of these capabilities (filtering, counting, logging) have + the potential to impose severe performance penalties, then this + otherwise rational course of action might not be possible. + + Warnings. + + Requirements for which performance is a particular concern + include: filtering, rate-limiting, counters, logging and anti- + spoofing. + + + + +Jones Informational [Page 66] + +RFC 3871 Operational Security Requirements September 2004 + + +3. Documentation Requirements + + The requirements in this section are intended to list information + that will assist operators in evaluating and securely operating a + device. + +3.1. Identify Services That May Be Listening + + Requirement. + + The vendor MUST provide a list of all services that may be active + on the device. The list MUST identify the protocols and default + ports (if applicable) on which the services listen. It SHOULD + provide references to complete documentation describing the + service. + + Justification. + + This information is necessary to enable a thorough assessment of + the potential security risks associated with the operation of each + service. + + Examples. + + The list will likely contain network and transport protocols such + as IP, ICMP, TCP, UDP, routing protocols such as BGP and OSPF, + application protocols such as SSH and SNMP along with references + to the RFCs or other documentation describing the versions of the + protocols implemented. + + Web servers "usually" listen on port 80. In the default + configuration of the device, it may have a web server listening on + port 8080. In the context of this requirement "identify ... + default port" would mean "port 8080". + + Warnings. + + There may be valid, non-technical reasons for not disclosing the + specifications of proprietary protocols. In such cases, all that + needs to be disclosed is the existence of the service and the + default ports (if applicable). + +3.2. Document Service Defaults + + Requirement. + + The vendor MUST provide a list of the default state of all + services. + + + +Jones Informational [Page 67] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + Understanding risk requires understanding exposure. Each service + that is enabled presents a certain level of exposure. Having a + list of the services that is enabled by default makes it possible + to perform meaningful risk analysis. + + Examples. + + The list may be no more than the output of a command that + implements Section 2.5.1. + + Warnings. + + None. + +3.3. Document Service Activation Process + + Requirement. + + The vendor MUST concisely document which features enable and + disable services. + + Justification. + + Once risk has been assessed, this list provides the operator a + quick means of understanding how to disable (or enable) undesired + (or desired) services. + + Examples. + + This may be a list of commands to enable/disable services one by + one or a single command which enables/disables "standard" groups + of commands. + + Warnings. + + None. + +3.4. Document Command Line Interface + + Requirement. + + The vendor MUST provide complete documentation of the command line + interface with each software release. The documentation SHOULD + include highlights of changes from previous versions. The + documentation SHOULD list potential output for each command. + + + + +Jones Informational [Page 68] + +RFC 3871 Operational Security Requirements September 2004 + + + Justification. + + Understanding of inputs and outputs is necessary to support + scripting. See Section 2.4.2. + + Examples. + + Separate documentation should be provided for each command listing + the syntax, parameters, options, etc. as well as expected output + (status, tables, etc.). + + Warnings. + + None. + +3.5. 'Console' Default Communication Profile Documented + + Requirement. + + The console default profile of communications parameters MUST be + published in the system documentation. + + Justification. + + Publication in the system documentation makes the settings + accessible. Failure to publish them could leave the operator + having to guess. + + Examples. + + None. + + Warnings. + + None. + +4. Assurance Requirements + + The requirements in this section are intended to + + o identify behaviors and information that will increase confidence + that the device will meet the security functional requirements. + + o Provide information that will assist in the performance of + security evaluations. + + + + + + +Jones Informational [Page 69] + +RFC 3871 Operational Security Requirements September 2004 + + +4.1. Identify Origin of IP Stack + + Requirement. + + The vendor SHOULD disclose the origin or basis of the IP stack + used on the system. + + Justification. + + This information is required to better understand the possible + security vulnerabilities that may be inherent in the IP stack. + + Examples. + + "The IP stack was derived from BSD 4.4", or "The IP stack was + implemented from scratch." + + Warnings. + + Many IP stacks make simplifying assumptions about how an IP packet + should be formed. A malformed packet can cause unexpected + behavior in the device, such as a system crash or buffer overflow + which could result in unauthorized access to the system. + +4.2. Identify Origin of Operating System + + Requirement. + + The vendor SHOULD disclose the origin or basis of the operating + system (OS). + + Justification. + + This information is required to better understand the security + vulnerabilities that may be inherent to the OS based on its + origin. + + Examples. + + "The operating system is based on Linux kernel 2.4.18." + + Warnings. + + None. + + + + + + + +Jones Informational [Page 70] + +RFC 3871 Operational Security Requirements September 2004 + + +5. Security Considerations + + General + + Security is the subject matter of this entire memo. The + justification section of each individual requirement lists the + security implications of meeting or not meeting the requirement. + + SNMP + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPSec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the + objects in the MIB. + + It is recommended that implementors consider the security features + as provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms + (for authentication and privacy). + + Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to MIB + objects is properly configured to give access to the objects only + to those principals (users) that have legitimate rights to indeed + GET or SET (change/create/delete) them. + +6. References + +6.1. Normative References + + [ANSI.X9-52.1998] American National Standards Institute, "Triple Data + Encryption Algorithm Modes of Operation", ANSI + X9.52, 1998. + + [FIPS.197] National Institute of Standards and Technology, + "Advanced Encryption Standard", FIPS PUB 197, + November 2001, + <http://csrc.nist.gov/publications/fips/fips197/ + fips-197.ps>. + + [PKCS.3.1993] RSA Laboratories, "Diffie-Hellman Key-Agreement + Standard, Version 1.4", PKCS 3, November 1993. + + [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking + terms", RFC 1208, March 1991. + + + +Jones Informational [Page 71] + +RFC 3871 Operational Security Requirements September 2004 + + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes + Called TACACS", RFC 1492, July 1993. + + [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September + 1993. + + [RFC1704] Haller, N. and R. Atkinson, "On Internet + Authentication", RFC 1704, October 1994. + + [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 + Routers", RFC 1812, June 1995. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de + Groot, G., and E. Lear, "Address Allocation for + Private Internets", BCP 5, RFC 1918, February 1996. + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC + 2196, September 1997. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version + 1.0", RFC 2246, January 1999. + + [RFC2385] Heffernan, A., "Protection of BGP Sessions via the + TCP MD5 Signature Option", RFC 2385, August 1998. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture + for the Internet Protocol", RFC 2401, November + 1998. + + [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement + Method", RFC 2631, June 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. + + + + + +Jones Informational [Page 72] + +RFC 3871 Operational Security Requirements September 2004 + + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. + Simpson, "Remote Authentication Dial In User + Service (RADIUS)", RFC 2865, June 2000. + + [RFC3013] Killalea, T., "Recommended Internet Service + Provider Security Services and Procedures", BCP 46, + RFC 3013, November 2000. + + [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, + August 2001. + + [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash + Algorithm 1 (SHA1)", RFC 3174, September 2001. + + [RFC3195] New, D. and M. Rose, "Reliable Delivery for + syslog", RFC 3195, November 2001. + + [RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control + Transmission Protocol (SCTP) Checksum Change", RFC + 3309, September 2002. + + [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, + September 2002. + + [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered + Harmful", BCP 60, RFC 3360, August 2002. + + [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, + "Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + December 2002. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network + Management Protocol (SNMP) Management Frameworks", + STD 62, RFC 3411, December 2002. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key + Cryptography Standards (PKCS) #1: RSA Cryptography + Specifications Version 2.1", RFC 3447, February + 2003. + + [RFC3562] Leech, M., "Key Management Considerations for the + TCP MD5 Signature Option", RFC 3562, July 2003. + + + + + + + +Jones Informational [Page 73] + +RFC 3871 Operational Security Requirements September 2004 + + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote + Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)", RFC + 3579, September 2003. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., + and J. Arkko, "Diameter Base Protocol", RFC 3588, + September 2003. + + [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, Eds., + "Security Mechanisms for the Internet", RFC 3631, + December 2003. + +6.2. Informative References + + [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths + For Public Keys Used For Exchanging Symmetric + Keys", BCP 86, RFC 3766, April 2004. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for + Multihomed Networks", BCP 84, RFC 3704, March 2004. + + [bmwg-acc-bench] Poretsky, S., "Framework for Accelerated Stress + Benchmarking", Work in Progress, October 2003. + + [Schneier] Schneier, B., "Applied Cryptography, 2nd Ed., + Publisher John Wiley & Sons, Inc.", 1996. + + + + + + + + + + + + + + + + + + + + + + + + +Jones Informational [Page 74] + +RFC 3871 Operational Security Requirements September 2004 + + +Appendix A. Requirement Profiles + + This Appendix lists different profiles. A profile is a list of list + of requirements that apply to a particular class of devices. The + minimum requirements profile applies to all devices. + +A.1. Minimum Requirements Profile + + The functionality listed here represents a minimum set of + requirements to which managed infrastructure of large IP networks + should adhere. + + The minimal requirements profile addresses functionality which will + provide reasonable capabilities to manage the devices in the event of + attacks, simplify troubleshooting, keep track of events which affect + system integrity, help analyze causes of attacks, as well as provide + administrators control over IP addresses and protocols to help + mitigate the most common attacks and exploits. + + o Support Secure Channels For Management + + o Use Protocols Subject To Open Review For Management + + o Use Cryptographic Algorithms Subject To Open Review + + o Use Strong Cryptography + + o Allow Selection of Cryptographic Parameters + + o Management Functions Should Have Increased Priority + + o Support a 'Console' Interface + + o 'Console' Communication Profile Must Support Reset + + o 'Console' Default Communication Profile Documented + + o 'Console' Requires Minimal Functionality of Attached Devices. + + o Support Separate Management Plane IP Interfaces + + o No Forwarding Between Management Plane And Other Interfaces + + o 'CLI' Provides Access to All Configuration and Management + Functions + + o 'CLI' Supports Scripting of Configuration + + + + +Jones Informational [Page 75] + +RFC 3871 Operational Security Requirements September 2004 + + + o 'CLI' Supports Management Over 'Slow' Links + + o Document Command Line Interface + + o Support Software Installation + + o Support Remote Configuration Backup + + o Support Remote Configuration Restore + + o Support Text Configuration Files + + o Ability to Identify All Listening Services + + o Ability to Disable Any and All Services + + o Ability to Control Service Bindings for Listening Services + + o Ability to Control Service Source Addresses + + o Ability to Filter Traffic + + o Ability to Filter Traffic TO the Device + + o Support Route Filtering + + o Ability to Specify Filter Actions + + o Ability to Log Filter Actions + + o Ability to Filter Without Significant Performance Degradation + + o Ability to Specify Filter Log Granularity + + o Ability to Filter on Protocols + + o Ability to Filter on Addresses + + o Ability to Filter on Protocol Header Fields + + o Ability to Filter Inbound and Outbound + + o Packet Filtering Counter Requirements + + o Ability to Display Filter Counters + + o Ability to Display Filter Counters per Rule + + + + +Jones Informational [Page 76] + +RFC 3871 Operational Security Requirements September 2004 + + + o Ability to Display Filter Counters per Filter Application + + o Ability to Reset Filter Counters + + o Filter Counters Must Be Accurate + + o Logging Facility Uses Protocols Subject To Open Review + + o Logs Sent To Remote Servers + + o Ability to Log Locally + + o Ability to Maintain Accurate System Time + + o Display Timezone And UTC Offset + + o Default Timezone Should Be UTC + + o Logs Must Be Timestamped + + o Logs Contain Untranslated IP Addresses + + o Logs Contain Records Of Security Events + + o Authenticate All User Access + + o Support Authentication of Individual Users + + o Support Simultaneous Connections + + o Ability to Disable All Local Accounts + + o Support Centralized User Authentication Methods + + o Support Local User Authentication Method + + o Support Configuration of Order of Authentication Methods + + o Ability To Authenticate Without Plaintext Passwords + + o Passwords Must Be Explicitly Configured Prior To Use + + o No Default Passwords + + o Ability to Define Privilege Levels + + o Ability to Assign Privilege Levels to Users + + + + +Jones Informational [Page 77] + +RFC 3871 Operational Security Requirements September 2004 + + + o Default Privilege Level Must Be 'None' + + o Change in Privilege Levels Requires Re-Authentication + + o Support Recovery Of Privileged Access + + o Logs Do Not Contain Passwords + + o Security Features Must Not Cause Operational Problems + + o Security Features Should Have Minimal Performance Impact + + o Identify Services That May Be Listening + + o Document Service Defaults + + o Document Service Activation Process + + o Identify Origin of IP Stack + + o Identify Origin of Operating System + + o Identify Origin of IP Stack + + o Identify Origin of Operating System + + o Layer 2 Devices Must Meet Higher Layer Requirements + +A.2. Layer 3 Network Edge Profile + + This section builds on the minimal requirements listed in A.1 and + adds more stringent security functionality specific to layer 3 + devices which are part of the network edge. The network edge is + typically where much of the filtering and traffic control policies + are implemented. + + An edge device is defined as a device that makes up the network + infrastructure and connects directly to customers or peers. This + would include routers connected to peering points, switches + connecting customer hosts, etc. + + o Support Automatic Anti-spoofing for Single-Homed Networks + + o Support Automatic Discarding Of Bogons and Martians + + o Support Counters For Dropped Packets + + o Support Rate Limiting + + + +Jones Informational [Page 78] + +RFC 3871 Operational Security Requirements September 2004 + + + o Support Directional Application Of Rate Limiting Per Interface + + o Support Rate Limiting Based on State + + o Ability to Filter Traffic THROUGH the Device + +Appendix B. Acknowledgments + + This document grew out of an internal security requirements document + used by UUNET for testing devices that were being proposed for + connection to the backbone. + + The editor gratefully acknowledges the contributions of: + o Greg Sayadian, author of a predecessor of this document. + + o Eric Brandwine, a major source of ideas/critiques. + + o The MITRE Corporation for supporting continued development of this + document. NOTE: The editor's affiliation with The MITRE + Corporation is provided for identification purposes only, and is + not intended to convey or imply MITRE's concurrence with, or + support for, the positions, opinions or viewpoints expressed by + the editor. + + o The former UUNET network security team: Jared Allison, Eric + Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent King, Neil + Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd MacDermid, + Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow, Robert Stone, + Anne Williams, Pete White. + + o Others who have provided significant feedback at various stages of + the life of this document are: Ran Atkinson, Fred Baker, Steve + Bellovin, David L. Black, Michael H. Behringer, Matt Bishop, Scott + Blake, Randy Bush, Pat Cain, Ross Callon, Steven Christey, Owen + Delong, Sean Donelan, Robert Elmore, Barbara Fraser, Barry Greene, + Jeffrey Haas, David Harrington, Dan Hollis, Jeffrey Hutzelman, + Merike Kaeo, James Ko, John Kristoff, Chris Lonvick, Chris + Liljenstolpe, James W. Laferriere, Jared Mauch, Perry E. Metzger, + Mike O'Connor, Alan Paller, Rob Pickering, Pekka Savola, Gregg + Schudel, Juergen Schoenwaelder, Don Smith, Rodney Thayer, David + Walters, Joel N. Weber II, Russ White, Anthony Williams, Neal + Ziring. + + o Madge B. Harrison and Patricia L. Jones, technical writing review. + + o This listing is intended to acknowledge contributions, not to + imply that the individual or organizations approve the content of + this document. + + + +Jones Informational [Page 79] + +RFC 3871 Operational Security Requirements September 2004 + + + o Apologies to those who commented on/contributed to the document + and were not listed. + +Author's Address + + George M. Jones, Editor + The MITRE Corporation + 7515 Colshire Drive, M/S WEST + McLean, Virginia 22102-7508 + U.S.A. + + Phone: +1 703 488 9740 + EMail: gmj3871@pobox.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jones Informational [Page 80] + +RFC 3871 Operational Security Requirements September 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Jones Informational [Page 81] + |