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.
2.4. Configuration and Management Interface Requirements
This section lists requirements that support secure device
configuration and management methods. In most cases, this currently
involves some sort of command line interface (CLI) and configuration
files. It may be possible to meet these requirements with other
mechanisms, for instance SNMP or a script-able HTML interface that
provides full access to management and configuration functions. In
the future, there may be others (e.g., XML based configuration).
2.4.1. ’CLI’ Provides Access to All Configuration and Management
Functions
Requirement.
The Command Line Interface (CLI) or equivalent MUST allow complete
access to all configuration and management functions. The CLI
MUST be supported on the console (see Section 2.3.1) and SHOULD be
supported on all other interfaces used for management.
Justification.
The CLI (or equivalent) is needed to provide the ability to do
reliable, fast, direct, local management and monitoring of a
device. It is particularly useful in situations where it is not
possible to manage and monitor the device in-band via "normal"