RFC 3871
Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure
RFC 3871: Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure 🎀
Okay bestie, this is RFC 3871 and it is giving security checklist for big ISP gear 💅. It was written by G. Jones, Ed., from The MITRE Corporation, in September 2004. It's labelled Informational, so it's sharing info with the Internet community rather than being an actual standard 🧚. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨.
Status of This Memo 🌸
This memo gives info to 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 🦋
Okay so this doc defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks, meaning the routers and switches 🔥. It also sets up a framework for specifying "profiles", which are collections of requirements that apply to certain network topology contexts (all, core-only, edge-only...) 🍓. The whole goal is to give network operators a clear, concise way of telling vendors what their security requirements are 💅✨.
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
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
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 . . . . . . . . . . . . . . . . . . . . . 811. Introduction 👑
1.1. Goals 🍓
Okay so the vibe here is that this doc defines a list of operational security requirements for the infrastructure of large IP networks, meaning the routers and switches 🌸. The whole goal is to give network operators a clear, concise way of communicating their security requirements to equipment vendors 💅.
1.2. Motivation 🌈
Network operators need tools so they can manage their networks securely, and so they can insure that they keep the ability to provide service to their customers 🫶. Some of the threats are outlined in section 3.2 of [RFC2196] 😭. This document lists features that 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] 🦋.
To be continued in part 2, bestie 💖🧚
1.3. Scope ✨
okay so the scope is the managed infrastructure of big ISP IP networks 🌐 think routers and switches, the stuff that actually moves everyone's traffic. some groups (aka "profiles", more on those later 🎀) only apply in specific situations, like edge-only setups.
these things are explicitly out of scope 🙅♀️:
- general purpose hosts that do not transit traffic, including infrastructure hosts like name/time/log/AAA servers, etc.,
- unmanaged devices,
- customer managed devices (e.g., firewalls, Intrusion Detection System, dedicated VPN devices, etc.),
- SOHO (Small Office, Home Office) devices (e.g., personal firewalls, Wireless Access Points, Cable Modems, etc.),
- confidentiality of customer data,
- integrity of customer data,
- physical security.
so basically, even if the minimum profile (and others) apply, extra requirements have not been added to cover their unique needs 🫶 that's on purpose, not an oversight!
the examples are written with IPv4 in mind, but most of the requirements are general enough to apply to IPv6 too. slay 💅
1.4. Definition of a Secure Network 🔐
for this doc, a secure network is one where:
- The network keeps passing legitimate customer traffic (availability).
- Traffic goes where it is supposed to go, and only where it is supposed to go (availability, confidentiality).
- The network elements remain manageable (availability).
- Only authorized users can manage network elements (authorization).
- There is a record of all security related events (accountability).
- The network operator has the necessary tools to detect and respond to illegitimate traffic.
1.5. Intended Audience 👀
there are two audiences here: the network operator who picks, buys, and runs IP network gear, and the vendors who make it.
1.6. Format 🗂️
the individual requirements are listed in three sections:
- Section 2 lists functional requirements.
- Section 3 lists documentation requirements.
- Section 4 lists assurance requirements.
inside those areas, requirements are grouped into major functional areas (e.g., logging, authentication, filtering, etc.)
every requirement has these subsections:
- Requirement (what)
- Justification (why)
- Examples (how)
- Warnings (if applicable)
the Requirement is the policy the device should support. the Justification explains why it matters and in what context. the Examples are implementations that may meet the requirement, and they cite technology and standards that were current when this was written, see [RFC3631]. it's expected that the implementations picked to meet the requirements will change over time 🦋 the Warnings list operational concerns, deviations from standards, caveats, etc.
security requirements vary across device types and organizations, depending on policy and other stuff. a feature you want in one environment might be a requirement in another, so classifications must be made according to local need 🌸
to help with classification, Appendix A defines a few requirement "profiles" for different device types. profiles are concise lists of requirements for certain classes of devices. the profiles in this doc should be reviewed to see if they fit your local environment.
1.7. Intended Use 🧚
the requirements in this doc are expected to be used for:
- a checklist when evaluating networked products,
- creating profiles of different subsets of the requirements that describe the needs of different devices, organizations, and operating environments,
- helping operators clearly communicate their security requirements,
- high level guidance for creating 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].
ok this is the important bit 🫶 the editor tried to assign the right requirement levels ("MUST", "SHOULD", "MAY"...), but different organizations, operating environments, policies and legal environments will end up with different levels. so operators and vendors should think carefully about each requirement 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 that has not yet been allocated by IANA or the Regional Internet Registries (ARIN, RIPE, APNIC...), as well as addresses reserved for private or special use by RFCs. See [RFC3330] and [RFC1918].
CLI.
Several requirements mention a Command Line Interface (CLI). right now that means a classic text oriented command interface, but it isn't meant to rule out other mechanisms that meet all the requirements that reference "CLI" 🖥️
Console.
Several requirements mention a "Console". the model here is the classic RS232 serial port, which has been a simple, stable, reliable, well-understood and nearly ubiquitous management interface for network devices for 30+ years 👑 again, these requirements mainly exist to capture the benefits of that legendary interface, not to block other mechanisms that meet the same requirements.
Filter.
in this doc, a "filter" is 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" means any management done over the same channels and interfaces used for user/customer data. for example, using SSH for management over customer or Internet facing network interfaces 🙈
High Resolution Time.
"High resolution time" is defined here as "time having a resolution greater than one second" (e.g., milliseconds) ⏱️
IP.
unless stated otherwise, "IP" means IPv4.
Management.
this doc uses a broad definition of "management". it refers to any authorized interaction with the device that is meant to change its operational state or configuration. data/forwarding plane functions (e.g., transit of customer traffic) are not management. control plane functions like routing, signaling and link management protocols, and management plane functions like remote access, configuration and authentication, are considered 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 this doc, 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 traffic can be asymmetric in some cases, and a simple forwarding table check might give false positives. See [RFC3704]
Out-of-Band (OoB) management.
"Out-of-Band management" means any management done over channels and interfaces that are separate from those used for user/customer data. examples are a serial console interface, or a network interface connected to a dedicated management network that doesn't carry customer traffic 🔌
Open Review.
"Open review" refers to processes designed to generate public discussion and review of proposed technical solutions, like data communications protocols and cryptographic algorithms, with the goal of improving them and building confidence in the final solutions 🧠
for this doc, "open review" is defined by [RFC2026]. all standards track documents are considered to have been through an open review process.
organizations can have local requirements that define what they consider acceptable "open review". for example, they may have to follow certain national or international standards. those changes to the definition of "open review" are important, but they're considered local issues that should be discussed between the organization and the vendor.
also, section 7 of [RFC2026] lets standards track documents incorporate other "external standards and specifications" 📚
Service.
a bunch of requirements mention "services". for this doc, a "service" is "any process or protocol running in the control or management planes to which non-transit packets may be delivered". examples are an SSH server, a BGP process or an NTP server. it also includes the transport, network and link layer protocols, because for example a TCP packet addressed to a port with no service listening will be "delivered" to the IP stack, and might 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 give confidentiality but possibly not integrity 🔒
Single-Homed Network.
a "single-homed network" is one for which:
- There is only one upstream connection
- Routing is symmetric.
See [RFC3704] for a discussion of related issues and mechanisms for multihomed networks.
Spoofed Packet.
a "spoofed packet" is a packet that has a source address that doesn't correspond to any address assigned to the system that sent the packet. spoofed packets are often "bogons" or "martians" 🎭
2. Functional Requirements 🛠️
the requirements in this section are meant to list testable, functional requirements needed to operate devices securely. let's gooo 🚀
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 so 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. Literally the whole point is keeping the bad guys out of the control room 🚪🙅♀️
Examples 🎀
See [RFC3631] for a current list of mechanisms that can be used to support secure management.
Later sections cover the requirements for in-band management (Section 2.2) and out-of-band management (Section 2.3), plus the trade-offs you need to weigh when deciding which one fits your situation. 🦋
Warnings ⚠️
None.
2.2. In-Band Management Requirements 🌸
This section lists the security requirements that support secure in-band management. In-band management is lowkey great because it's cheaper (no extra interfaces or lines 💸), but it has some serious security downsides, bestie 😭
- Saturating customer lines or interfaces can make the device unmanageable, unless out-of-band management resources have been reserved.
- Since public interfaces and channels are used, attackers can directly address and reach the device and try to perform management functions. 👀
- In-band management traffic on public interfaces may be intercepted, but this would typically require a significant compromise of the routing system.
- Public interfaces used for in-band management may become unavailable because of bugs (e.g., buffer overflows being exploited), while out-of-band interfaces (such as a serial console device) remain available. 💀
There are lots of situations where in-band management makes sense, is used, or is the only option, so these requirements are here to help secure 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 haven't been through widespread, extended public or peer review are more likely to have undiscovered weaknesses or flaws than open standards and publicly reviewed algorithms. Network operators may need or want to use non-open cryptographic algorithms, and they should be allowed to weigh the trade-offs and make an informed choice between open and non-open cryptography. See [Schneier] for further discussion. 📚
Examples 🎀
At the time of writing, these algorithms satisfy the requirement: 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 field changes fast, so what's good enough today may not be good enough in the future. 🏃♀️
Open review is necessary but not sufficient. The strength of the algorithm and the key length also need to be considered. For example, 56-bit DES meets the open review requirement, but it's considered too weak today 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. Not it! 🙅♀️
Examples 🎀
At the time of writing, these algorithms satisfy the requirement: 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.
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 using such hashes in deployed products and protocols is preferable to having no integrity and authentication checks at all, this document agrees 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 field changes fast, so what's good enough today may not be good enough in the future.
Strength is relative. Long keys and strong algorithms are meant to increase the work factor needed to compromise the data they protect. Over time, as processing power grows, the security a given algorithm and key length provides will degrade, so the definition of "strong" has to be constantly reevaluated. 📈
There may be legal issues governing the use of cryptography and the strength of the cryptography used. ⚖️
This document explicitly does not make any authoritative statement about which key lengths count as "strong" cryptography. See [RFC3562] and [RFC3766] for help 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. 💅
Justification 🧐
Protocols that haven't been through widespread, extended public or peer review are more likely to have undiscovered weaknesses or flaws than open standards and publicly reviewed protocols. Network operators may need or want to use non-open protocols, and they should be allowed to weigh the trade-offs and make an informed choice between open and non-open protocols. 🤓
Examples 🎀
See TLS [RFC2246] and IPsec [RFC2401].
Warnings ⚠️
Open review is necessary but may not be sufficient. It's perfectly possible for an openly reviewed protocol to misuse (or not use) cryptography. Main character, but make it secure 🎬
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 and "weak" at another. Constantly increasing compute power keeps shrinking the time needed to break cryptography of a given strength, and weaknesses may be discovered in algorithms. Being able to select a different algorithm is a super useful tool for staying secure when those discoveries happen. 🔄
Examples 🎀
56-bit DES was once considered secure. In 1998 it was cracked by a custom-built machine in under 3 days. 😱 Being able to select algorithms and key lengths gives the operator options (different algorithms, longer keys) when developments like that happen.
Warnings ⚠️
None.
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, like link congestion, memory exhaustion, or CPU overload. When that happens, it's important that management functions get prioritized so operators have the tools they need to recover from the attack. 🛠️
Examples 🎀
Imagine a service provider with 1,000,000 DSL subscribers, most of whom have no firewall protection. Now imagine that a large portion of these subscribers' machines were infected with a new worm that enabled them to be used in a coordinated fashion as part of a large denial-of-service attack involving flooding. It's entirely possible that, without prioritization, such an attack would cause link congestion that results 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, and processing). If 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 versus out-of-band management. 💕
These requirements assume two possible out-of-band topologies:
- serial line (or equivalent) console connections using a CLI,
- network interfaces connected to a separate network dedicated to management.
The following assumptions are made about out-of-band management:
- The out-of-band management network is secure.
- Communications beyond the management interface (e.g., console port, management network interface) are secure.
- 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).
- 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.
bestie, the device MUST support complete configuration and management via a 'console' interface that works totally independently from the forwarding and IP control planes. no network needed, no vibes lost 💅
Justification.
okay so there are times when you NEED to get into a device right now, even if the network is down 😭 routing and interfaces could be misconfigured, the IP stack or OS might be broken (or vulnerable to brand new exploits that make using them impossible or just a bad idea 💀), or the high-bandwidth paths to the device might be gone. in those moments, a console interface gives you a way to manage and configure the device. it's the emergency exit and it's giving safety ✨
Examples.
an RS232 (EIA232) interface that lets you load new system software and configure things through a command line interface. RS232 ports are everywhere and everyone understands them 🌸
a simple embedded device that gives you management and configuration access over an Ethernet or USB interface. also iconic 🧚
as of this writing, RS232 is still strongly recommended, and honestly it's giving because of these perks:
- Simplicity. RS232 is way simpler than the alternatives. It's just a hardware specification. An Ethernet-based solution might need an ethernet interface, an operating system, an IP stack and an HTTP server all working and configured properly, which is a LOT 😩
- Proven. RS232 has been around for more than 30 years 👑
- Well-Understood. operators have tons of experience with it 🫶
- Availability. it still works even when the network fails 🦋
- Ubiquity. it's super widely deployed in mid to high end network infrastructure 🌈
- Low-Cost. adding an RS232 port to a device costs very little 💜
- CLI-Friendly. an RS232 interface plus a CLI is enough in most cases to manage a device. no extra software needed ✨
- Integrated. operators already have loads of solutions (terminal servers and so on) deployed to support management over RS232 🍓
while other interfaces may be supplied, the properties above should be considered. interfaces that don't have these properties may be tricky to use, integrate or adopt. and problems in any of those areas could cause negative security impacts, especially when the console has to be used to respond to incidents quickly 🚨
Warnings.
it's common practice to connect RS232 ports to terminal servers that allow networked access, just for convenience. but that increases the potential security exposure of the mechanisms that are only supposed to be reachable via RS232 ports 🙈 for example, a password recovery mechanism that's only available over RS232 might let a remote hacker completely reconfigure a router. >:( operational procedures are beyond the scope of this document, but it's important to note that strong attention should be given to policies, procedures, access mechanisms and physical security governing access to console ports. this is NOT the place to slack 😤
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.
guessing at communication settings wastes time, and time is everything in a crisis 😭 the operator may need to get on the console of a device fast.
Examples.
one method might be to send a break on a serial line 🧃
Warnings.
None. no drama here, bestie ✨
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. no gatekeeping!! 💅
Justification.
the whole point of the console interface is to have a management interface that can be made to work quickly at all times. if attached devices need complex or nonstandard behavior, the console is way less likely to work without hassles 😩
Examples.
if the console is supplied via an RS232 interface, then it should work with an attached device that only implements a "dumb" terminal. support for "advanced" terminal features and types should be optional. the bare minimum slaying 🌷
Warnings.
None. 🫶
2.3.4. 'Console' Supports Fall-back Authentication 🔐
Requirement.
the 'console' SHOULD support an authentication mechanism that doesn't need 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 if you can't get into the device with it when the network is down 💀
Examples.
some devices that use TACACS or RADIUS for authentication will fall back to a local account if the TACACS or RADIUS server doesn't reply to an authentication request. the backup plan is literally iconic ✨
Warnings.
this requirement is a trade-off between being able to manage the device (functionality) and security 🥺 there are lots of ways to implement it that would weaken the device's security, like a back door for unauthorized access. no thank you 🙅♀️ local policy should be consulted to decide whether "fail open" or "fail closed" is the right stance. and the implications of "fail closed" (like not being able to manage a device) should be fully considered.
if the fall-back mechanism is disabled, it's important that a failure of the IP-based authentication mechanism gets reliably detected and the fall-back mechanism automatically enabled. otherwise the operator might be left with no way to authenticate at all 😱
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. optional but lowkey smart 🌸
Justification.
a separate management plane interface lets management traffic be segregated from the other traffic (data/forwarding plane, control plane). that lowers the risk that unauthorized people can observe management traffic and/or compromise the device 🔒
this requirement applies in situations where a separate OoB management network exists.
Examples.
an Ethernet port that's dedicated to management and isolated from customer traffic satisfies this requirement 💜
Warnings.
using this type of interface depends on the operating system and the IP stack both functioning properly, plus good, known configuration at least on the parts of the device dedicated to management. no shortcuts, babe 🎀
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. the walls go UP 🧱
Justification.
this stops management traffic, whether intentional or unintentional, from flowing to or from places where it should never be originating or terminating (for example, anything beyond the customer-facing interfaces) 🙈
Examples.
implementing separate forwarding tables for management plane and non-management plane interfaces that don't propagate routes to each other satisfies this requirement. two separate worlds, zero drama ✨
Warnings.
None. 🫶
2.4. Configuration and Management Interface Requirements 💻
this section lists requirements that support secure device configuration and management methods. right now, this mostly means some sort of command line interface (CLI) and configuration files. it may be possible to meet these requirements with other mechanisms, like SNMP or a scriptable HTML interface that gives full access to management and configuration functions. in the future there may be others (like 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. the CLI is the main character 👑
Justification.
the CLI (or equivalent) is needed for reliable, fast, direct, local management and monitoring of a device 🔥 it's especially useful when you can't manage and monitor the device in-band through "normal" means (like SSH or SNMP [RFC3410], [RFC3411]) that depend on working networking. that situation happens a lot during security incidents, like bandwidth-based denial of service attacks 😭
Examples.
configuration examples include setting interface addresses, defining and applying filters, configuring logging and authentication, etc. management function examples include displaying dynamic state information like 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 the one in Section 2.4.1. scripts > clicking around 💅
Justification.
during security incidents, you often need to make configuration changes on huge numbers of devices really quickly. doing that by hand is error-prone and slow 🥱 vendor-supplied management solutions don't always anticipate the type or scale of solutions that are needed. scripting is the glow-up that solves 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 currently used for scripting include expect, Perl and TCL 🌈
Warnings.
some properties of the command language that make scripting easier are simplicity, regularity and consistency 🍓 some implementations that would make scripting hard or impossible include "text menu" style interfaces (like "curses" on UNIX), or hard-coded GUI interfaces (like a native Windows or Macintosh GUI application) that talk over a proprietary or undocumented protocol that isn't based on a CLI. bestie, don't build scripting out of the picture 💀
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. Okay, so, sometimes you don't have high bandwidth for management, like when your in-band connections are overloaded during an attack, or when you're stuck using a low-bandwidth out-of-band connection like a modem. 😭 And honestly? These are the exact moments you most need to be able to manage and configure things. Main character problems, but make it stressful. 💀
Examples. Picture this: the network is down. The network engineer accidentally disabled routing on the only gateway router in a remote unmanned data center. 🙈 The only way in is a modem hooked up to a console port. The data center customers are blowing up the support line. Meanwhile the GUI management interface is redrawing the screen multiple times... slowly... at 9600bps. Nightmare fuel. 😩
One mechanism that makes slow links workable is being able to filter the output of CLI commands that might be huge. It can be built with something similar to the UNIX pipe facility and the "grep" command, like this:
cat largefile.txt | grep interesting-stringAnother option is being able to "page" through big command output, like the UNIX "more" command:
cat largefile.txt | moreWarnings. One consequence of this requirement is that a GUI-only management interface may be unacceptable, unless it can be shown to work acceptably over slow links. Bestie, the GUI needs to prove itself first. 🫶
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 admins go to lunch. 🥪 They leave themselves logged in with administrative privileges. They forget to use password-protected screensavers. They do all this at conferences and in other public places. Not okay. That behavior hands unauthorized people an opportunity, and idle timeouts shrink that window of exposure. Lock it down, babe. 🔐
Examples. The CLI may provide a configuration command that lets someone set an idle timeout. If the operator doesn't enter any commands for that amount of time, the login session gets terminated automatically. Logged out, no drama. 🦋
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 get discovered in base software (operating systems, etc.) that vendors ship, and no cap, the only real fix is often a vendor update (bug fixes, new versions of code, etc.). Without a way to load new vendor code, you might not be able to fix the risk those vulnerabilities create. 😤
- Hackers or even operators making honest mistakes can corrupt or erase software on devices. When that happens, you need a way to (re)load software onto the device so it works again. 🧯
- Loading new software while disconnected from all public IP networks is important, because the device could be exposed to old attacks before the update is finished. 🙅♀️
- You have to assume that hackers, operators, etc. might erase or corrupt all writable media (disks, flash, etc.). So you need to be able to recover starting from nothing but non-writable media (e.g., CD-ROM, a true ROM-based monitor). Iconic survival kit energy. 🧚
- System images can get corrupted in transit (from vendor to customer, or during the loading process) or while sitting in storage (bit rot, defective media, etc.). If you can't reliably load a new image, for example after a hacker deletes or corrupts the installed one, you could end up with a long outage. 😭
Examples. The device could support booting into a simple ROM-based monitor that handles a set of commands good enough 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.
- FLASH. The device could support booting from flash memory cards.
Simple mechanisms already in use to protect the integrity of system images and data transfers include image checksums and simple serial file transfer protocols such as XMODEM and Kermit. Old-school, but still bussin. 📼
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 for auditing and recovery. No archive, no receipts. 🧾
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. Making sure that's handled properly is outside the scope of this document, so that's on you, bestie. 🫶
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. ✨
Justification. Restoring archived configurations lets you get service back up quickly after an outage, whether it was security related or caused by something else. Glow-up arc: from broken to back online. 🌈
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.
Also, if passwords or other sensitive information were excluded from the saved copy of the configuration (which Section 2.4.6 allows), the restore might not be complete. The operator may have to set new passwords or supply other information that wasn't 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 text configs make it easier for humans to understand the device's operational state, enable off-line audits, and make automation easier too. Needing a proprietary program to read the config blocks all of that. Gatekeeping, we don't do that here. 🚫
Examples. A 7-bit ASCII configuration file that shows the current settings of the various configuration options would satisfy the requirement. A Unicode configuration would too, or any other "textual" representation. A structured binary format meant only for programs to read would not be acceptable. Sorry, robots only is a no. 🤖❌
Warnings. Offline copies of configurations should be well protected, because they often contain sensitive information such as SNMP community strings, passwords, network blocks, customer information, etc. Guard them like your diary. 🔒💜
"Well defined" and "textual" are open to interpretation. Clearly, an ASCII configuration file with a regular, documented command-oriented syntax would meet the definition, and these are in wide use right now. Future options, such as XML based configuration, may meet the requirement too. Determining that will take 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 info is necessary for a thorough assessment of the security risks that come with running the device. Like, "does this protocol allow complete management of the device without also requiring authentication, authorization, or accounting?" Spicy question, right? 🌶️ It also helps you figure out what to do about the risk, like "should I turn this service off?" 🤔
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 providing a command that displays that fact. Easy peasy. 🧃
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. Being able to disable services with no operational need lets administrators lower the overall risk to the device. Less exposed stuff, less drama. 🧹
Examples. Processes that listen on TCP and UDP ports are the prime examples of services that must be possible to disable. Those are the ones to shut off first, periodt. 🙌
Warnings. None.
2.5.3. Ability to Control Service Bindings for Listening Services ✨
Requirement. Okay bestie, 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. Operators literally love to set up "loopback" pseudo-interfaces 🌸 and use them as the source and destination of management traffic. They're the main character here because they give a stable, routable address. Services bound to physical interface addresses can go unreachable if the hardware dies, gets yanked out, etc. 😭
This requirement lets you lock down management services with routing 🔒 Management services can be bound only to loopback addresses, and those loopbacks can come from net-blocks that are only routed between the managed devices and the authorized management networks/hosts. The result? Nobody can connect to (or try to DoS) the management services unless they're coming from those authorized networks/hosts. Iconic 👑
It also cuts down on the need for complex filters 🧹 Fewer ports listening means fewer potential avenues of attack. And it makes sure only traffic from legitimate addresses and/or on designated interfaces can reach services on the device. Periodt 💜
Examples. If the device listens for inbound SSH connections, this requirement means you should be able to say the device will only listen to connections destined for specific addresses (e.g., the loopback interface's address) or received on certain interfaces (e.g., an Ethernet interface designated as the "management" interface) 🧚 In this example it should be possible to configure the device so SSH is NOT listening on every address configured on the device. Similar effects can be achieved with 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 lets the user 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 🫶
Justification. This lets remote devices receiving connections or transmissions use source filtering as one form 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 set up to accept SNMP packets only from that address 🎀
Examples. The operator may allocate a distinct block of addresses that all loopbacks are numbered from 🌈 NTP and syslog can be set to use those loopback addresses as source, while SNMP and BGP may be set to use specific physical interface addresses 💅 This makes source-address filtering easier, which is one way to reject unauthorized attempts to connect to peers/servers. Slay 😤
Warnings. Be careful that the addresses you pick are routable between the sending and receiving devices 🚧 (e.g., setting SSH to use a loopback address of 10.1.1.1 that isn't routed between a router and all intended destinations could cause problems 💀).
Also note that some protocols, such as SCTP [RFC3309], can use more than one IP address as the endpoint of a single connection 🌸
Also, [RFC3631] lists address-based authentication as an "insecurity mechanism" 🚨 Address-based authentication should be replaced or augmented by other mechanisms wherever possible. Not me reading this and going "wait, it's not safe?" 😭
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 those interfaces where applying 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 🌀
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 🧩 One option is a single command that automatically generates and applies filters to an interface doing anti-spoofing. Another is a command that checks the return path for received packets against the current forwarding tables, and drops them if they wouldn't be forwarded back out the interface they came in on 🔁
See [RFC3704]. ✨
Warnings. This requirement only holds for single-homed networks 🏠 Note that a simple forwarding table check is NOT enough in the more complex scenarios of multi-homed or multi-attached networks, i.e., where the traffic may be asymmetric 🌪️ In those 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 packets have little (no?) legitimate use 🤷♀️ They're mostly used to let people dodge identification (and thus accountability), and they seem to show up most in DoS attacks, email abuse, hacking, etc. 😤 On top of that, transiting them needlessly eats up resources and can cause capacity and performance problems for customers 📉
See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of [RFC1812], and [RFC2827]. 📚
Examples. This requirement could be satisfied by a command that checks the return path for received packets against the current forwarding tables, and drops them if no viable return path exists 🧹 This assumes steps are taken to make sure 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 enough in the more complex scenarios of multi-homed or multi-attached networks, i.e., where the traffic may be asymmetric 🌪️ In those 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 you figure out where spoofed traffic is coming from 🕵️♀️
Examples. Picture an edge router with a bunch of single-homed customers attached 🏢 When an attack using spoofed packets gets detected, a quick check of the counters might tell you exactly which customer is trying to send spoofed traffic. Detective era 🔎
Warnings. None. 🙈
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 passes 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 is a way to reduce or eliminate the impact of certain attacks 🛡️ Rate limiting also has the advantage that, in some cases, it can be turned on a priori 🕰️ That gives you some ability to soften the effect of future attacks before any explicit operator reaction to them. Preventative era ✨
Examples. Let's say a web hosting company rents space in its data-center to a company that becomes unpopular with a certain element of network users 😬 Those users decide to flood the web server with inbound ICMP traffic 🌊 In that situation, it would be super useful to rate-filter inbound ICMP traffic at the data-center's border routers 🧱
Now the other side 💀 A new worm gets released that infects vulnerable database servers, so they start spewing traffic on TCP port 1433 aimed at random destination addresses, as fast as the infected server's system and network interface can manage 😱 Say a data center has tons of vulnerable servers infected and all sending huge amounts of traffic at once, so every outbound link is saturated 🔥 With this requirement, the network operator could 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 keep service levels up for other legitimate customers/traffic 🦸♀️
Warnings. None. 🙈
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 lets you aim your controls precisely, so you minimize the impact on third parties 🎀
Examples. If an ICMP flood is directed at a single customer on an edge router, it may be appropriate to rate-limit outbound ICMP only on that customer's 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 lets you respond appropriately to certain classes of attack 🛡️
Examples. For TCP sessions, it should be possible to rate limit based on the SYN, SYN-ACK, RST, or other bit state. Flag-watching era 👀
Warnings. None. 🙈
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.
Okay so this one is the big foundational filtering requirement 💅✨ The device MUST be able to filter IP packets on any interface that runs IP, no cap. Why it matters: filtering is how you actually enforce which traffic is allowed and which isn't, and it's also your basic weapon against malicious traffic 🛡️ Example vibe: access control lists that filter on protocol, source/destination address, and/or source/destination port. Iconic. 🎀
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.
Warnings.
None.
Bestie, this one is about traffic aimed AT the device itself 🧚 It MUST be possible to filter that traffic on any interface, loopback ones included 🌸 The point is protecting the box from attacks and unauthorized access. Example energy: only let BGP in from peers, let SNMP and SSH in from an authorized management segment going to the device, and drop everything else addressed to it. Main character protection 👑
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.
Now the transit side 🦋 It MUST be possible to filter traffic that's being routed or switched THROUGH the device, which is basically how you run policy on routers, switches, and anything else carrying transit traffic 💖 A super common way to do it is filtering inbound on each interface and/or outbound from each interface. Ingress filtering per [RFC2827] is one example of that in action.
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.
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.
Okay, performance is where it gets spicy 🌶️ The device MUST filter packets without significant performance degradation, and this specifically covers stateless filtering on layer 3 (IP) and layer 4 (TCP or UDP) headers, plus normal forwarding info like incoming and outgoing interfaces 🎀 The device MUST also be able to run stateless packet filters on ALL interfaces (up to the max possible) at the same time, with multiple filters per interface, like inbound AND outbound 🔥
Why it matters: filtering can't become the bottleneck. Example: if a device forwards 30Mb/sec without filtering, it should forward the same amount with filtering on 💅
⚠️ Warnings tea: "significant" is subjective 💀 It could be anything from "the box might crash" to "less than one percent throughput loss with tens of thousands of filters." The acceptable level is for the operator to decide 🫶
Repeatable test data is super useful for checking conformance 📊 Good tests include packet size, packet rate, number of interfaces tested (source/destination), interface types, routing table size, routing protocols in use, frequency of routing updates, etc. See [bmwg-acc-bench] 🌈
And finally, this requirement does NOT cover stateful filtering, filtering above layer 4 headers, or other advanced filtering that might matter in certain 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.
Route filtering time 🗺️ The device MUST be able to filter routing updates for every protocol used to exchange external routing info. Check out [RFC3013] and section 3.2 of [RFC2196] for the backstory 📚 Operators might want to ignore route advertisements for private internet address space. See eBGP 🦋
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.
Filter actions, the fun part 🎬 The device MUST have a mechanism for specifying what happens when a filter rule matches. The actions MUST include "permit" (let the traffic through), "reject" (drop it with a notification to the sender), and "drop" (drop it with NO notification to the sender). Also see Section 2.7.7 and Section 2.9 🎀
Why it matters: this is essential for using filters to enforce policy 💅
Picture a small DMZ connected to the internet 🏢 You want SSH management coming from your corporate office. So you "permit" port 22 from the corporate network and "reject" everything else on port 22. Corporate SSH gets through ✨ Everyone else on port 22 gets an ICMP message back. If you're extra paranoid, you can "drop" their traffic instead, so nothing goes back to the source 🙈
⚠️ Okay, real talk: silently dropping can be the right call security-wise, but think about the operational side too. See [RFC3360] for the mess that inappropriate TCP Resets can cause 💀
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),
- 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.
Logging time 📝 It MUST be possible to log ALL filter actions, and the logging MUST capture at least:
- permit/deny/drop status,
- source and destination IP address,
- source and destination ports (if applicable to the protocol),
- 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 🫶
This is essential for auditing, incident response, and operations 🔍 Example: a desktop network with no services that should be reachable from "outside" should log all inbound connection attempts as possible intrusion attempts 👀
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.
Filter on protocols 🎀 The device MUST provide a way to filter traffic based on the value of the protocol field in the IP header. This is necessary for policy, secure operations, and incident response 💅
Example: some DoS attacks flood the victim with ICMP traffic 🌊 One quick mitigation (with some side effects, ngl) is dropping all ICMP traffic headed toward the victim 🛡️
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.
Address filtering 🗺️ The function MUST be able to control traffic flow based on source and/or destination IP address, or blocks of addresses like CIDR blocks. It's a fundamental tool for drawing boundaries between networks 🧱 One example is ingress filtering per [RFC2827] 💖
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 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.
Header fields, let's go 🧩 The filtering mechanism MUST support filtering on any portion of the IP, ICMP, UDP and TCP headers. It SHOULD support other protocols at layers 3 and 4 too, and it MAY support higher-level protocol headers. It SHOULD also let you name fields (like "protocol = ICMP") instead of bit-offset/length/numeric values (like 72:8 = 1) 🎀
This is necessary for policy and incident response 💅 It implies filtering on TCP or UDP port numbers, TCP flags like SYN, ACK and RST, and ICMP type and code fields ✨ A classic move is rejecting "inbound" TCP connection attempts (SYN bit set with ACK bit clear, or SYN bit set with ACK, FIN and RST bits clear) 🙅 Another is controlling which services get in and out of a network, like only allowing inbound connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting web servers 🌐
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.
Inbound AND outbound 🔁 It MUST be possible to filter both incoming and outgoing traffic on any interface. This lets you put filters wherever they make the most sense, and drop invalid or malicious traffic as close to the source as possible 🌸
Example: on a border router, you might put an egress filter outbound on the interface connecting your site to its external ISP, dropping outbound traffic without a valid internal source address 💅 Inbound, you could block all traffic from a site known for sending lots of junk mail 📧
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.
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.
Counting time 🔢 The device MUST supply a facility for accurately counting ALL filter hits 🎀 Why it matters: counting rule matches shows how often people try to break policy, so you can focus your resources where they're needed 💅
Example: an ISP runs anti-spoofing egress filters (see [RFC2827]) on its edge routers that serve single-homed stub networks 🛰️ Counters can flag big spikes of spoofed packets, which might mean a customer is doing something sketchy (possibly violating the ISP's Acceptable Use Policy), or that their network got "owned" by hackers and is being (mis)used to launch attacks 😭 Yikes, bestie 🥺
2.9.2. Ability to Display Filter Counters ✨
Requirement 💖
The device MUST provide a mechanism to display filter counters. 🫶
Justification 🎀
okay so collecting the data is cute, but if you can't actually see it in a useful way, it's basically just vibes 💀 literally useless unless you can read it.
Examples 🧚
Picture a router with four interfaces. One is an up-link to an ISP that gives it routes to the Internet, and the other three connect to separate internal networks. 🌸 Now say a host on one of the internal networks gets compromised by a hacker and starts sending traffic with bogus source addresses. 😭 In that situation, it might be smart to put ingress filters on each of the internal interfaces. Once the filters are running, you can check the counters to figure out which source (the inbound interface) is sending the bogus packets. 🕵️♀️
Warnings 🙈
None.
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 lets you see which rules are matching and how often. main character energy, honestly 👑
Examples 💅
Say you've got a filter with two rules. The first one permits all SSH traffic (tcp/22), and the second one drops everything else. ✨ If three packets come toward or through the spot where the filter is applied, one going to port 22 and the other two going 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 🍓
Sometimes it makes sense to apply the same filter definition at the same time in more than one place (different interfaces, etc.). 🧚 If that's happening, it's way more useful to know which instance is matching than to just know that some instance matched somewhere. 😤
Examples 🎀
One way to do this is to have the counter display show the interface (or other entity) the filter is applied to, along with the filter's name (or other designator). 💅 For example, if a filter named "desktop_outbound" is applied to two interfaces, say "ethernet0" and "ethernet1", the display should show 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 fine for the system to keep two counters: an "absolute counter", C[now], and a "reset" counter, C[reset]. 🫶 The absolute counter keeps counts that go up monotonically until they wrap or overflow the counter. 📈 The reset counter gets a copy of the absolute counter's current value whenever the reset function is run for that counter. ✨ After that, the functions that display or retrieve the counter can show the delta, C[now] - C[reset]. 🧮
Justification 🌸
This lets operators get a current picture of the traffic matching particular rules and filters. 👀
Examples 💜
Imagine filter counters are being used to find internal hosts infected with a brand new worm. 🪱 Once everyone believes all the infected hosts have been cleaned up and the worm is gone, the next move is to verify it. One way to do that is to reset the filter counters to zero and see whether worm-like traffic has stopped. 🙏
Warnings 🙈
None.
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 trusted as the basis for action, bestie. ❌ Underreported data can hide how big a problem actually is. 🫠
Examples 🧚
If N packets matching a filter are sent to or through a device, then the counter should show N matches. ✨ Simple, clean, iconic 💅
Warnings 🙈
None.
2.10. Other Packet Filtering Requirements 🎀
2.10.1. Ability to Specify Filter Log Granularity 🦋
Requirement 🌈
It MUST be possible to enable or disable logging on a per rule basis. 🫶
Justification 💜
Being able to tune how granular your logging is means the operator only logs what they actually want. 🎯 Without this, you could end up with extra data (or none at all) getting logged, which makes it way harder to find the relevant stuff. 😵💫
Examples 🍓
Say a filter has several rules, and one of them denies telnet (tcp/23) connections. Then it should be possible to set things up so that only matches on the telnet-denying rule generate a log message. 🙅♀️📝
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 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 🌸
Logging based on open-review protocols lets the operator archive and analyze logs without depending on vendor-supplied software and servers. 🙌 That's the freedom you want, periodt 🕊️
Examples 🧚
This requirement may be satisfied by using 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 or 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:
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 a big deal because it supports individual accountability. 🫡 It's also important to store logs on a separate server, so they survive if the managed device fails or gets compromised. 🛡️
Examples 💜
This requirement may be satisfied by using 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 or 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 matters to the extent that people depend on log data for operational decisions and forensic analysis. 🔍 Without it, log data is just a collection of hints. 🫠
Examples 🦋
One example of reliable syslog delivery is defined in [RFC3195]. Syslog-ng provides another example, although that protocol has not been standardized. ✨
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 🔐
Logging failed authentication attempts locally to non-volatile storage is critical. 🚨 It lets you detect attacks where the device has been cut off from its authentication interfaces and is being attacked at the console. 🖥️😱
Local logging is also key for viewing information when you're connected to the device. 👩💻 It gives some backup of log data in case remote logging fails. 🛟 And it gives you a way to look at logs for one device without digging through a potentially huge pile of logs from other devices. 🧹✨
Examples 🧚
One example of local logging is a memory buffer that receives copies of messages sent to the remote log server. 🧠 Another might be a local syslog server (assuming the device can run syslog and has some local storage). 📦
Warnings ⚠️
Storage on the device may be limited. High volumes of logging may quickly fill the available storage, and then there are two options: new logs overwrite old logs (possibly through 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. 🕰️
Justification 🌈
Accurate time is essential for generating reliable log data. ✨ It also matters for 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 by a 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 it possible to correlate data and coordinate with data from other timezones. 🌏 That's the whole point, bestie 💖
Examples 🧚
Bob is in Newfoundland, Canada, which is UTC -3:30. Alice is somewhere in Indiana, USA, where some parts switch to daylight savings time while others don't. 🗺️ 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 the timezone, or better yet the UTC offset, clears all of that up. 🎀✨
Warnings 🙈
None.
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.
Okay so knowing the timezone or UTC offset is what makes it possible to correlate data and line it up with data from other timezones ✨
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. 🫶 That's the dream, bestie: zero time math 🧚
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 the main character of event correlation 💅 They matter a lot when you're lining events up 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.
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 the IP address for access list violations, authentication attempts, address lease assignments and similar events in logs gives you a level of individual and organizational accountability. It's also necessary for analyzing network events, incidents, policy violations, etc. 🦋
DNS entries tend to change more quickly than IP block assignments. That 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 individuals, 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. ⏳
- 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. ⚖️
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"). Relatable, honestly 😭
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.
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.
Individual accounts plus logging = accountability, period 📖 Group or default accounts undermine individual accountability, so they're a no from me 🙅♀️
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. Iconic behavior, no notes 💖
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 is defined as one where all information necessary for user authentication is stored on the device. 📦
Justification.
Default accounts, well-known accounts, and old accounts are easy targets for someone trying to gain access to a device 🎯 It must be possible to disable them to reduce the potential vulnerability. Clean up your accounts, bestie 🧼
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. 🌐
Justification.
Support for centralized authentication is especially important in large environments where network devices are widely distributed and where many people have access to them. It 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. 🔐
Warnings.
Authentication information must be protected wherever it resides 🚨 Having, for instance, local usernames and passwords stored on 100 network devices means there are 100 potential points of failure where the information could be compromised 😱 Compare that to storing authentication data on centralized server(s), which would reduce the potential points of failure to the number of servers and let protection efforts (system hardening, audits, etc.) focus on, at most, a few servers. Much more manageable, no cap 🫶
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. It's giving balance ⚖️
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.
Justification. Okay, plaintext passwords are way too easy to spy on when lots of people share a network with packet sniffers. Go read [RFC1704] and [RFC3631] for a through discussion. 🕵️♀️
Examples. Remote login always means sending auth info across the network. Telnet sends plaintext passwords, so it's giving no privacy 💀. SSH doesn't send them in plaintext, so SSH passes and Telnet fails. ✨
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 are basically a free pass for attackers to walk right into the device. 🚪💀
Examples. Passwords like the vendor's name, the device name, "default", and stuff like that are super easy to guess, so no thank you 🙅♀️. The SNMP community strings "public" and "private" are famous defaults that give read and write access to devices. Iconic for all the wrong reasons 😭.
Warnings. Lists of default passwords for tons of devices are totally available on loads of websites. Yikes. 🙈
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.
Justification. This one is about keeping unauthorized folks out of management access 🔐. When operators have to set passwords themselves, you usually end up with a variety of passwords instead of the same one everywhere 🌈. It also puts the job of picking a password on the user, which is honestly the right energy 👑.
Examples. Say a device comes with a console port for management and a default administrative account. This requirement, together with No Default Passwords, means that account should come with no password configured 🧚. One way to meet this is to have the device ask the operator to choose a password for the administrative account as part of a little dialog the first time it gets configured. Clean and cute 🎀.
Warnings. Even though this device makes operators set passwords, it can't stop them from using scripts to configure hundreds of devices with the same easily guessed password. Scripts are not it 💀.
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 is all about the principle of "least privilege" 🦋, which says an individual should only have the privileges they need to do the operations they're supposed to do. Give people only what they need, bestie 💖.
Examples. Some privilege levels could be "user", which only lets you start a PPP or telnet session; "read only", which lets you look at device configuration and operational statistics but not touch them; "root/superuser/administrator", which allows update access to every configurable parameter; and "operator", which allows updates to a limited, user-defined set of parameters. Privilege levels can be defined locally on the device or on centralized authentication servers, so there's options 🌸.
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. Same "least privilege" energy as before 🦋. Only the stuff you need, nothing extra. Obsessed with it, honestly 😤.
Examples. This is gonna be super tied to the authentication mechanism, obviously 🙃. If RADIUS is in use, an attribute can be set in the user's RADIUS profile to map the ID to a certain privilege level. Cute little link 🔗.
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.
Justification. Same "least privilege" vibes 🦋. The people who only need to do the basics shouldn't get the keys to the whole kingdom 👑.
Examples. Some privilege levels could be "user", which only lets you start a PPP or telnet session; "read-only", which lets you look at device configuration and operational statistics; "root/superuser/administrator", which allows update access to every configurable parameter; and "operator", which allows updates to a limited, user-defined set of parameters. Privilege levels can be defined locally on the device or on centralized authentication servers 🧚.
Warnings. Sometimes you'll need exceptions so this requirement doesn't block recovery of privileged access (Section 2.12.15) or OS installation and configuration (Section 2.4.5). Like, if the OS or configuration gets corrupted, someone authorized with physical access might need "root" level access just to do an install. Real life is messy 🙈.
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 makes sure users can only do the things they're actually authorized to do. No sneaking around 🕵️♀️.
Examples. One way to do this is to give all users base privilege levels, then let them request extra privileges, with those requests getting checked by the AAA server. Gatekeeping, but make it cute 💅.
Warnings. None. 💜
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. Real talk, people forget local admin passwords all the time 😭. Sometimes the only person who knew it leaves the company, or hackers set or change it. In all of those cases, legit admin access is gone, so there should be a way to get it back 🔑. Requiring physical access makes it way less likely to get abused 🛡️. Some orgs want even tighter security and are willing to risk losing all authorized access by disabling the recovery feature, even for people who have physical access. Bold choice, but valid ✨.
Examples. A few ways to satisfy this requirement are to have the device give the user a chance to set a new admin 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, so it may not be appropriate for environments where people with physical access can not be trusted. Major 🚨.
Also see the warnings in Section 2.3.1 (Support a 'Console' Interface). 🎀
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, so they should be held to similar requirements. Fair is fair 🤝.
Examples. Signaling protocols needed for layer 2 switching may swap information with other devices using layer 3 communications. In those 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. Everything has to be secure, no exceptions 💅.
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 that wreck operations are not useful, and they might leave the operator with no way to enforce appropriate policy. Not a vibe 💀.
Examples. Some examples of severe operational problems include:
- The device crashes.
- The device becomes unmanageable.
- Data is lost.
- Use of the security feature consumes excessive resources (CPU, memory, bandwidth).
Warnings. Deciding whether this requirement is met takes a level of judgement 🧐. What counts as "severe"? Crashing is obviously severe, but what about a %5 loss in throughput when logging is turned on? 🤔 It should also be noted that there may be unavoidable physical limitations, like the total capacity of a link. Physics is not our friend 🌸.
2.15. Security Features Should Have Minimal Performance Impact ✨
Requirement. Bestie, security features covered by the requirements in this document SHOULD be implemented with minimal impact on performance 💖 Other sections might set different performance requirements (e.g., "MUST"s).
Justification. Security features that seriously hurt performance can leave the operator with no way to enforce appropriate policy 😭
Examples. If applying filters is known to possibly slow down traffic that isn't filtered, people will be tempted, or sometimes even told, not to use filters at all 🙈
Say a new worm drops that scans random IP addresses looking for services listening on TCP port 1433 🦋 An operator might want to check whether any hosts on their network are infected and trying to spread it. One way to do that is to put up non-blocking filters that count and log outbound connections to port 1433, then block the requests determined to come from infected hosts. If any of those capabilities (filtering, counting, logging) could cause severe performance penalties, this totally rational plan might not be possible 💀
Warnings. Performance is a particular worry for filtering, rate-limiting, counters, logging and anti-spoofing 🫶
3. Documentation Requirements ✨
The requirements in this section are meant to list information that helps operators evaluate and securely operate 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 info is necessary so people can do a thorough assessment of the potential security risks of running each service 🔍
Examples. The list will likely include network and transport protocols like IP, ICMP, TCP and UDP, routing protocols like BGP and OSPF, and application protocols like SSH and SNMP. It should also have references to the RFCs or other docs describing the protocol versions implemented 🍓
Web servers "usually" listen on port 80. In the default configuration, the device might have a web server listening on port 8080. In this requirement, "identify ... default port" would mean "port 8080" 🧚
Warnings. There may be valid, non-technical reasons for not disclosing the specs of proprietary protocols. In that case, all that needs to be disclosed is that the service exists and its default ports (if applicable) 🔥
3.2. Document Service Defaults
Requirement. The vendor MUST provide a list of the default state of all services.
Justification. Understanding risk requires understanding exposure. Every enabled service comes with a certain level of exposure, so a list of what's on by default makes meaningful risk analysis possible 📊
Examples. The list can 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 the risk has been assessed, this list gives the operator a quick way to figure out how to disable undesired services (or enable desired ones) 🏃♀️
Examples. This could be a list of commands that enable or disable services one by one, or a single command that enables or 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.
Justification. Knowing the inputs and outputs is necessary to support scripting. See Section 2.4.2. 🤖
Examples. Each command should get its own documentation listing the syntax, parameters, options, etc., as well as the 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. Publishing these settings in the system documentation makes them accessible. Without it, the operator is left guessing 🕵️♀️
Examples. None.
Warnings. None.
4. Assurance Requirements ✨
The requirements in this section are intended to:
- identify behaviors and information that will increase confidence that the device will meet the security functional requirements.
- Provide information that will assist in the performance of security evaluations.
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 info helps people understand the possible security vulnerabilities that may be built into 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, like 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 info helps people understand the security vulnerabilities that may be inherent to the OS based on where it came from 🧐
Examples. "The operating system is based on Linux kernel 2.4.18."
Warnings. None.
5. Security Considerations 🔥
Security is the subject matter of this entire memo, bestie. The justification section of each individual requirement lists the security implications of meeting or not meeting that requirement 💜
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
Versions of SNMP before SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPSec), there is still no control over 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 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 before SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer or operator responsibility to make sure the SNMP entity giving access to MIB objects is properly configured, so that only the principals (users) with legitimate rights can 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.
- [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.
- [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.
- [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.
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. 🔥
- Support Secure Channels For Management
- Use Protocols Subject To Open Review For Management
- Use Cryptographic Algorithms Subject To Open Review
- Use Strong Cryptography
- Allow Selection of Cryptographic Parameters
- Management Functions Should Have Increased Priority
- Support a 'Console' Interface
- 'Console' Communication Profile Must Support Reset
- 'Console' Default Communication Profile Documented
- 'Console' Requires Minimal Functionality of Attached Devices.
- Support Separate Management Plane IP Interfaces
- No Forwarding Between Management Plane And Other Interfaces
- 'CLI' Provides Access to All Configuration and Management Functions
- 'CLI' Supports Scripting of Configuration
- 'CLI' Supports Management Over 'Slow' Links
- Document Command Line Interface
- Support Software Installation
- Support Remote Configuration Backup
- Support Remote Configuration Restore
- Support Text Configuration Files
- Ability to Identify All Listening Services
- Ability to Disable Any and All Services
- Ability to Control Service Bindings for Listening Services
- Ability to Control Service Source Addresses
- Ability to Filter Traffic
- Ability to Filter Traffic TO the Device
- Support Route Filtering
- Ability to Specify Filter Actions
- Ability to Log Filter Actions
- Ability to Filter Without Significant Performance Degradation
- Ability to Specify Filter Log Granularity
- Ability to Filter on Protocols
- Ability to Filter on Addresses
- Ability to Filter on Protocol Header Fields
- Ability to Filter Inbound and Outbound
- Packet Filtering Counter Requirements
- Ability to Display Filter Counters
- Ability to Display Filter Counters per Rule
- Ability to Display Filter Counters per Filter Application
- Ability to Reset Filter Counters
- Filter Counters Must Be Accurate
- Logging Facility Uses Protocols Subject To Open Review
- Logs Sent To Remote Servers
- Ability to Log Locally
- Ability to Maintain Accurate System Time
- Display Timezone And UTC Offset
- Default Timezone Should Be UTC
- Logs Must Be Timestamped
- Logs Contain Untranslated IP Addresses
- Logs Contain Records Of Security Events
- Authenticate All User Access
- Support Authentication of Individual Users
- Support Simultaneous Connections
- Ability to Disable All Local Accounts
- Support Centralized User Authentication Methods
- Support Local User Authentication Method
- Support Configuration of Order of Authentication Methods
- Ability To Authenticate Without Plaintext Passwords
- Passwords Must Be Explicitly Configured Prior To Use
- No Default Passwords
- Ability to Define Privilege Levels
- Ability to Assign Privilege Levels to Users
- Default Privilege Level Must Be 'None'
- Change in Privilege Levels Requires Re-Authentication
- Support Recovery Of Privileged Access
- Logs Do Not Contain Passwords
- Security Features Must Not Cause Operational Problems
- Security Features Should Have Minimal Performance Impact
- Identify Services That May Be Listening
- Document Service Defaults
- Document Service Activation Process
- Identify Origin of IP Stack
- Identify Origin of Operating System
- Identify Origin of IP Stack
- Identify Origin of Operating System
- 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. 🧚
- Support Automatic Anti-spoofing for Single-Homed Networks
- Support Automatic Discarding Of Bogons and Martians
- Support Counters For Dropped Packets
- Support Rate Limiting
- Support Directional Application Of Rate Limiting Per Interface
- Support Rate Limiting Based on State
- Ability to Filter Traffic THROUGH the Device
Appendix B. Acknowledgments 💖
okay so this doc grew out of an internal security requirements document that UUNET used for testing devices they wanted to connect to the backbone 🧚 that's such a main character origin story fr
the editor gave major shoutouts to:
- Greg Sayadian, author of a predecessor of this doc 🌸
- Eric Brandwine, a major source of ideas and critiques 💅
- The MITRE Corporation, for supporting the continued development of this doc. 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. 🫶
- 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. 👑
- Everyone else who gave significant feedback at different stages of this doc's life: 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. 🌈
- Madge B. Harrison and Patricia L. Jones, for the technical writing review 🍓
- This list is meant to thank people for their contributions. It does not mean that any of these individuals or organizations approve of what's in this doc ✨
- Apologies to anyone who commented on or contributed to the doc and didn't make the list 🙈
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.comFull Copyright Statement
Copyright (C) The Internet Society (2004). This doc is covered by the rights, licenses and restrictions in BCP 78. Other than what's set out there, the authors keep all of their rights 💜
This doc and the info in it are handed over "AS IS." Honestly, the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all say no to every warranty, express or implied. That includes no promise that using the info here won't infringe any rights, and no implied warranties of merchantability or fitness for a particular purpose 💀
The full disclaimer, as written: 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 doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this doc are valid or how far they reach. It also doesn't say whether any license under those rights is available. It hasn't done any independent digging to find out about those rights either 🦋 If you want the rules on rights in RFC docs, check BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone interested to let it know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📩
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 🎀✨
📦 where this page comes from
- ietf: rfc3871 2004-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms