RFC 3871
Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure
Network Working Group G. Jones, Ed. Request for Comments: 3871 The MITRE Corporation Category: Informational September 2004 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).Abstract
This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.
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 . . . . . . . . . . . . . . . . . . . . . 81
1. Introduction
1.1. Goals
This document defines a list of operational security requirements for the infrastructure of large IP networks (routers and switches). The goal is to provide network operators a clear, concise way of communicating their security requirements to equipment vendors.1.2. Motivation
Network operators need tools to ensure that they are able to manage their networks securely and to insure that they maintain the ability to provide service to their customers. Some of the threats are outlined in section 3.2 of [RFC2196]. This document enumerates features which are required to implement many of the policies and procedures suggested by [RFC2196] in the context of the infrastructure of large IP-based networks. Also see [RFC3013].1.3. Scope
The scope of these requirements is intended to cover the managed infrastructure of large ISP IP networks (e.g., routers and switches). Certain groups (or "profiles", see below) apply only in specific situations (e.g., edge-only). The following are explicitly out of scope: o general purpose hosts that do not transit traffic including infrastructure hosts such as name/time/log/AAA servers, etc., o unmanaged devices, o customer managed devices (e.g., firewalls, Intrusion Detection System, dedicated VPN devices, etc.), o SOHO (Small Office, Home Office) devices (e.g., personal firewalls, Wireless Access Points, Cable Modems, etc.), o confidentiality of customer data, o integrity of customer data, o physical security. This means that while the requirements in the minimum profile (and others) may apply, additional requirements have not be added to account for their unique needs.
While the examples given are written with IPv4 in mind, most of the requirements are general enough to apply to IPv6.1.4. Definition of a Secure Network
For the purposes of this document, a secure network is one in which: o The network keeps passing legitimate customer traffic (availability). o Traffic goes where it is supposed to go, and only where it is supposed to go (availability, confidentiality). o The network elements remain manageable (availability). o Only authorized users can manage network elements (authorization). o There is a record of all security related events (accountability). o The network operator has the necessary tools to detect and respond to illegitimate traffic.1.5. Intended Audience
There are two intended audiences: the network operator who selects, purchases, and operates IP network equipment, and the vendors who create them.1.6. Format
The individual requirements are listed in the three sections below. o Section 2 lists functional requirements. o Section 3 lists documentation requirements. o Section 4 lists assurance requirements. Within these areas, requirements are grouped in major functional areas (e.g., logging, authentication, filtering, etc.) Each requirement has the following subsections: o Requirement (what) o Justification (why) o Examples (how)
o Warnings (if applicable) The requirement describes a policy to be supported by the device. The justification tells why and in what context the requirement is important. The examples section is intended to give examples of implementations that may meet the requirement. Examples cite technology and standards current at the time of this writing. See [RFC3631]. It is expected that the choice of implementations to meet the requirements will change over time. The warnings list operational concerns, deviation from standards, caveats, etc. Security requirements will vary across different device types and different organizations, depending on policy and other factors. A desired feature in one environment may be a requirement in another. Classifications must be made according to local need. In order to assist in classification, Appendix A defines several requirement "profiles" for different types of devices. Profiles are concise lists of requirements that apply to certain classes of devices. The profiles in this document should be reviewed to determine if they are appropriate to the local environment.1.7. Intended Use
It is anticipated that the requirements in this document will be used for the following purposes: o as a checklist when evaluating networked products, o to create profiles of different subsets of the requirements which describe the needs of different devices, organizations, and operating environments, o to assist operators in clearly communicating their security requirements, o as high level guidance for the creation of detailed test plans.1.8. Definitions
RFC 2119 Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The use of the RFC 2119 keywords is an attempt, by the editor, to
assign the correct requirement levels ("MUST", "SHOULD",
"MAY"...). It must be noted that different organizations,
operational environments, policies and legal environments will
generate different requirement levels. Operators and vendors
should carefully consider the individual requirements listed here
in their own context. One size does not fit all.
Bogon.
A "Bogon" (plural: "bogons") is a packet with an IP source address
in an address block not yet allocated by IANA or the Regional
Internet Registries (ARIN, RIPE, APNIC...) as well as all
addresses reserved for private or special use by RFCs. See
[RFC3330] and [RFC1918].
CLI.
Several requirements refer to a Command Line Interface (CLI).
While this refers at present to a classic text oriented command
interface, it is not intended to preclude other mechanisms which
may meet all the requirements that reference "CLI".
Console.
Several requirements refer to a "Console". The model for this is
the classic RS232 serial port which has, for the past 30 or more
years, provided a simple, stable, reliable, well-understood and
nearly ubiquitous management interface to network devices. Again,
these requirements are intended primarily to codify the benefits
provided by that venerable interface, not to preclude other
mechanisms that meet all the same requirements.
Filter.
In this document, a "filter" is defined as a group of one or more
rules where each rule specifies one or more match criteria as
specified in Section 2.8.
In-Band management.
"In-Band management" is defined as any management done over the
same channels and interfaces used for user/customer data.
Examples would include using SSH for management via customer or
Internet facing network interfaces.
High Resolution Time.
"High resolution time" is defined in this document as "time having
a resolution greater than one second" (e.g., milliseconds).
IP.
Unless otherwise indicated, "IP" refers to IPv4.
Management.
This document uses a broad definition of the term "management".
In this document, "management" refers to any authorized
interaction with the device intended to change its operational
state or configuration. Data/Forwarding plane functions (e.g.,
the transit of customer traffic) are not considered management.
Control plane functions such as routing, signaling and link
management protocols and management plane functions such as remote
access, configuration and authentication are considered to be
management.
Martian.
Per [RFC1208] "Martian: Humorous term applied to packets that turn
up unexpectedly on the wrong network because of bogus routing
entries. Also used as a name for a packet which has an altogether
bogus (non-registered or ill-formed) Internet address." For the
purposes of this document Martians are defined as "packets having
a source address that, by application of the current forwarding
tables, would not have its return traffic routed back to the
sender." "Spoofed packets" are a common source of martians.
Note that in some cases, the traffic may be asymmetric, and a
simple forwarding table check might produce false positives. See
[RFC3704]
Out-of-Band (OoB) management.
"Out-of-Band management" is defined as any management done over
channels and interfaces that are separate from those used for
user/customer data. Examples would include a serial console
interface or a network interface connected to a dedicated
management network that is not used to carry customer traffic.
Open Review.
"Open review" refers to processes designed to generate public
discussion and review of proposed technical solutions such as data
communications protocols and cryptographic algorithms with the
goals of improving and building confidence in the final solutions.
For the purposes of this document "open review" is defined by
[RFC2026]. All standards track documents are considered to have
been through an open review process.
It should be noted that organizations may have local requirements
that define what they view as acceptable "open review". For
example, they may be required to adhere to certain national or
international standards. Such modifications of the definition of
the term "open review", while important, are considered local
issues that should be discussed between the organization and the
vendor.
It should also be noted that section 7 of [RFC2026] permits
standards track documents to incorporate other "external standards
and specifications".
Service.
A number of requirements refer to "services". For the purposes of
this document a "service" is defined as "any process or protocol
running in the control or management planes to which non-transit
packets may be delivered". Examples might include an SSH server,
a BGP process or an NTP server. It would also include the
transport, network and link layer protocols since, for example, a
TCP packet addressed to a port on which no service is listening
will be "delivered" to the IP stack, and possibly result in an
ICMP message being sent back.
Secure Channel.
A "secure channel" is a mechanism that ensures end-to-end
integrity and confidentiality of communications. Examples include
TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a
console port using physically secure, shielded cable would provide
confidentiality but possibly not integrity.
Single-Homed Network.
A "single-homed network" is defined as one for which
* There is only one upstream connection
* Routing is symmetric.
See [RFC3704] for a discussion of related issues and mechanisms
for multihomed networks.
Spoofed Packet.
A "spoofed packet" is defined as a packet that has a source
address that does not correspond to any address assigned to the
system which sent the packet. Spoofed packets are often "bogons"
or "martians".
2. Functional Requirements
The requirements in this section are intended to list testable,
functional requirements that are needed to operate devices securely.
2.1. Device Management Requirements
2.1.1. Support Secure Channels For Management
Requirement.
The device MUST provide mechanisms to ensure end-to-end integrity
and confidentiality for all network traffic and protocols used to
support management functions. This MUST include at least
protocols used for configuration, monitoring, configuration backup
and restore, logging, time synchronization, authentication, and
routing.
Justification.
Integrity protection is required to ensure that unauthorized users
cannot manage the device or alter log data or the results of
management commands. Confidentiality is required so that
unauthorized users cannot view sensitive information, such as
keys, passwords, or the identity of users.
Examples.
See [RFC3631] for a current list of mechanisms that can be used to
support secure management.
Later sections list requirements for supporting in-band management
(Section 2.2) and out-of-band management (Section 2.3) as well as
trade-offs that must be weighed in considering which is
appropriate to a given situation.
Warnings.
None.
2.2. In-Band Management Requirements
This section lists security requirements that support secure in-band
management. In-band management has the advantage of lower cost (no
extra interfaces or lines), but has significant security
disadvantages:
o Saturation of customer lines or interfaces can make the device
unmanageable unless out-of-band management resources have been
reserved.
o Since public interfaces/channels are used, it is possible for
attackers to directly address and reach the device and to attempt
management functions.
o In-band management traffic on public interfaces may be
intercepted, however this would typically require a significant
compromise in the routing system.
o Public interfaces used for in-band management may become
unavailable due to bugs (e.g., buffer overflows being exploited)
while out-of-band interfaces (such as a serial console device)
remain available.
There are many situations where in-band management makes sense, is
used, and/or is the only option. The following requirements are
meant to provide means of securing in-band management traffic.
2.2.1. Use Cryptographic Algorithms Subject To Open Review
Requirement.
If cryptography is used to provide secure management functions,
then there MUST be an option to use algorithms that are subject to
"open review" as defined in Section 1.8 to provide these
functions. These SHOULD be used by default. The device MAY
optionally support algorithms that are not open to review.
Justification.
Cryptographic algorithms that have not been subjected to
widespread, extended public/peer review are more likely to have
undiscovered weaknesses or flaws than open standards and publicly
reviewed algorithms. Network operators may have need or desire to
use non-open cryptographic algorithms. They should be allowed to
evaluate the trade-offs and make an informed choice between open
and non-open cryptography. See [Schneier] for further discussion.
Examples.
The following are some algorithms that satisfy the requirement at
the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998]
for applications requiring symmetric encryption; RSA [RFC3447] and
Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring
key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications
requiring message verification.
Warnings.
This list is not exhaustive. Other strong, well-reviewed
algorithms may meet the requirement. The dynamic nature of the
field means that what is good enough today may not be in the
future.
Open review is necessary but not sufficient. The strength of the
algorithm and key length must also be considered. For example,
56-bit DES meets the open review requirement, but is today
considered too weak and is therefore not recommended.
2.2.2. Use Strong Cryptography
Requirement.
If cryptography is used to meet the secure management channel
requirements, then the key lengths and algorithms SHOULD be
"strong".
Justification.
Short keys and weak algorithms threaten the confidentiality and
integrity of communications.
Examples.
The following algorithms satisfy the requirement at the time of
writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] for
applications requiring symmetric encryption; RSA [RFC3447] and
Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring
key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications
requiring message verification.
Note that for *new protocols* [RFC3631] says the following:
"Simple keyed hashes based on MD5 [RFC1321], such as that used in
the BGP session security mechanism [RFC2385], are especially to be
avoided in new protocols, given the hints of weakness in MD5."
While use of such hashes in deployed products and protocols is
preferable to a complete lack of integrity and authentication
checks, this document concurs with the recommendation that new
products and protocols strongly consider alternatives.
Warnings.
This list is not exhaustive. Other strong, well-reviewed
algorithms may meet the requirement. The dynamic nature of the
field means that what is good enough today may not be in the
future.
Strength is relative. Long keys and strong algorithms are
intended to increase the work factor required to compromise the
security of the data protected. Over time, as processing power
increases, the security provided by a given algorithm and key
length will degrade. The definition of "Strong" must be
constantly reevaluated.
There may be legal issues governing the use of cryptography and
the strength of cryptography used.
This document explicitly does not attempt to make any
authoritative statement about what key lengths constitute "strong"
cryptography. See [RFC3562] and [RFC3766] for help in
determining appropriate key lengths. Also see [Schneier] chapter
7 for a discussion of key lengths.
2.2.3. Use Protocols Subject To Open Review For Management
Requirement.
If cryptography is used to provide secure management channels,
then its use MUST be supported in protocols that are subject to
"open review" as defined in Section 1.8. These SHOULD be used by
default. The device MAY optionally support the use of
cryptography in protocols that are not open to review.
Justification.
Protocols that have not been subjected to widespread, extended
public/peer review are more likely to have undiscovered weaknesses
or flaws than open standards and publicly reviewed protocols
Network operators may have need or desire to use non-open
protocols They should be allowed to evaluate the trade-offs and
make an informed choice between open and non-open protocols.
Examples.
See TLS [RFC2246] and IPsec [RFC2401].
Warnings.
Note that open review is necessary but may not be sufficient. It
is perfectly possible for an openly reviewed protocol to misuse
(or not use) cryptography.
2.2.4. Allow Selection of Cryptographic Parameters
Requirement.
The device SHOULD allow the operator to select cryptographic
parameters. This SHOULD include key lengths and algorithms.
Justification.
Cryptography using certain algorithms and key lengths may be
considered "strong" at one point in time, but "weak" at another.
The constant increase in compute power continually reduces the
time needed to break cryptography of a certain strength.
Weaknesses may be discovered in algorithms. The ability to select
a different algorithm is a useful tool for maintaining security in
the face of such discoveries.
Examples.
56-bit DES was once considered secure. In 1998 it was cracked by
custom built machine in under 3 days. The ability to select
algorithms and key lengths would give the operator options
(different algorithms, longer keys) in the face of such
developments.
Warnings.
None.
2.2.5. Management Functions Should Have Increased Priority
Requirement. Management functions SHOULD be processed at higher priority than non-management traffic. This SHOULD include ingress, egress, internal transmission, and processing. This SHOULD include at least protocols used for configuration, monitoring, configuration backup, logging, time synchronization, authentication, and routing. Justification. Certain attacks (and normal operation) can cause resource saturation such as link congestion, memory exhaustion or CPU overload. In these cases it is important that management functions be prioritized to ensure that operators have the tools needed to recover from the attack. Examples. Imagine a service provider with 1,000,000 DSL subscribers, most of whom have no firewall protection. Imagine that a large portion of these subscribers machines were infected with a new worm that enabled them to be used in coordinated fashion as part of large denial of service attack that involved flooding. It is entirely possible that without prioritization such an attack would cause link congestion resulting in routing adjacencies being lost. A DoS attack against hosts has just become a DoS attack against the network. Warnings. Prioritization is not a panacea. Routing update packets may not make it across a saturated link. This requirement simply says that the device should prioritize management functions within its scope of control (e.g., ingress, egress, internal transit, processing). To the extent that this is done across an entire network, the overall effect will be to ensure that the network remains manageable.2.3. Out-of-Band (OoB) Management Requirements
See Section 2.2 for a discussion of the advantages and disadvantages of In-band vs. Out-of-Band management.
These requirements assume two different possible Out-of-Band
topologies:
o serial line (or equivalent) console connections using a CLI,
o network interfaces connected to a separate network dedicated to
management.
The following assumptions are made about out-of-band management:
o The out-of-band management network is secure.
o Communications beyond the management interface (e.g., console
port, management network interface) is secure.
o There is no need for encryption of communication on out-of-band
management interfaces, (e.g., on a serial connection between a
terminal server and a device's console port).
o Security measures are in place to prevent unauthorized physical
access.
Even if these assumptions hold it would be wise, as an application of
defense-in-depth, to apply the in-band requirements (e.g.,
encryption) to out-of-band interfaces.
2.3.1. Support a 'Console' Interface
Requirement.
The device MUST support complete configuration and management via
a 'console' interface that functions independently from the
forwarding and IP control planes.
Justification.
There are times when it is operationally necessary to be able to
immediately and easily access a device for management or
configuration, even when the network is unavailable, routing and
network interfaces are incorrectly configured, the IP stack and/or
operating system may not be working (or may be vulnerable to
recently discovered exploits that make their use impossible/
inadvisable), or when high bandwidth paths to the device are
unavailable. In such situations, a console interface can provide
a way to manage and configure the device.
Examples.
An RS232 (EIA232) interface that provides the capability to load
new versions of the system software and to perform configuration
via a command line interface. RS232 interfaces are ubiquitous and
well understood.
A simple embedded device that provides management and
configuration access via an Ethernet or USB interface.
As of this writing, RS232 is still strongly recommended as it
provides the following benefits:
* Simplicity. RS232 is far simpler than the alternatives. It is
simply a hardware specification. By contrast an Ethernet based
solution might require an ethernet interface, an operating
system, an IP stack and an HTTP server all to be functioning
and properly configured.
* Proven. RS232 has more than 30 years of use.
* Well-Understood. Operators have a great deal of experience
with RS232.
* Availability. It works even in the presence of network
failure.
* Ubiquity. It is very widely deployed in mid to high end
network infrastructure.
* Low-Cost. The cost of adding a RS232 port to a device is
small.
* CLI-Friendly. An RS232 interface and a CLI are sufficient in
most cases to manage a device. No additional software is
required.
* Integrated. Operators have many solutions (terminal servers,
etc.) currently deployed to support management via RS232.
While other interfaces may be supplied, the properties listed
above should be considered. Interfaces not having these
properties may present challenges in terms of ease of use,
integration or adoption. Problems in any of these areas could
have negative security impacts, particularly in situations
where the console must be used to quickly respond to incidents.
Warnings.
It is common practice is to connect RS232 ports to terminal
servers that permit networked access for convenience. This
increases the potential security exposure of mechanisms available
only via RS232 ports. For example, a password recovery mechanism
that is available only via RS232 might give a remote hacker to
completely reconfigure a router. While operational procedures are
beyond the scope of this document, it is important to note here
that strong attention should be given to policies, procedures,
access mechanisms and physical security governing access to
console ports.
2.3.2. 'Console' Communication Profile Must Support Reset
Requirement.
There MUST be a method defined and published for returning the
console communication parameters to their default settings. This
method must not require the current settings to be known.
Justification.
Having to guess at communications settings can waste time. In a
crisis situation, the operator may need to get on the console of a
device quickly.
Examples.
One method might be to send a break on a serial line.
Warnings.
None.
2.3.3. 'Console' Requires Minimal Functionality of Attached Devices
Requirement.
The use of the 'console' interface MUST NOT require proprietary
devices, protocol extensions or specific client software.
Justification.
The purpose of having the console interface is to have a
management interface that can be made to work quickly at all
times. Requiring complex or nonstandard behavior on the part of
attached devices reduces the likelihood that the console will work
without hassles.
Examples.
If the console is supplied via an RS232 interface, then it should
function with an attached device that only implements a "dumb"
terminal. Support of "advanced" terminal features/types should be
optional.
Warnings.
None.
2.3.4. 'Console' Supports Fall-back Authentication
Requirement.
The 'console' SHOULD support an authentication mechanism which
does not require functional IP or depend on external services.
This authentication mechanism MAY be disabled until a failure of
other preferred mechanisms is detected.
Justification.
It does little good to have a console interface on a device if you
cannot get into the device with it when the network is not
working.
Examples.
Some devices which use TACACS or RADIUS for authentication will
fall back to a local account if the TACACS or RADIUS server does
not reply to an authentication request.
Warnings.
This requirement represents a trade-off between being able to
manage the device (functionality) and security. There are many
ways to implement this which would provide reduced security for
the device, (e.g., a back door for unauthorized access). Local
policy should be consulted to determine if "fail open" or "fail
closed" is the correct stance. The implications of "fail closed"
(e.g., not being able to manage a device) should be fully
considered.
If the fall-back mechanism is disabled, it is important that the
failure of IP based authentication mechanism be reliably detected
and the fall-back mechanism automatically enabled...otherwise the
operator may be left with no means to authenticate.
2.3.5. Support Separate Management Plane IP Interfaces
Requirement.
The device MAY provide designated network interface(s) that are
used for management plane traffic.
Justification.
A separate management plane interface allows management traffic to
be segregated from other traffic (data/forwarding plane, control
plane). This reduces the risk that unauthorized individuals will
be able to observe management traffic and/or compromise the
device.
This requirement applies in situations where a separate OoB
management network exists.
Examples.
Ethernet port dedicated to management and isolated from customer
traffic satisfies this requirement.
Warnings.
The use of this type of interface depends on proper functioning of
both the operating system and the IP stack, as well as good, known
configuration at least on the portions of the device dedicated to
management.
2.3.6. No Forwarding Between Management Plane And Other Interfaces
Requirement.
If the device implements separate network interface(s) for the
management plane per Section 2.3.5 then the device MUST NOT
forward traffic between the management plane and non-management
plane interfaces.
Justification.
This prevents the flow, intentional or unintentional, of
management traffic to/from places that it should not be
originating/terminating (e.g., anything beyond the customer-facing
interfaces).
Examples.
Implementing separate forwarding tables for management plane and
non-management plane interfaces that do not propagate routes to
each other satisfies this requirement.
Warnings.
None.
(page 22 continued on part 2)
