GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3871

Network Working Group G. Jones, Ed. Request for Comments: 3871 The MITRE Corporation Category: Informational September 2004

            Operational Security Requirements for Large
     Internet Service Provider (ISP) IP Network Infrastructure

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This document defines a list of operational security requirements for
 the infrastructure of large Internet Service Provider (ISP) IP
 networks (routers and switches).  A framework is defined for
 specifying "profiles", which are collections of requirements
 applicable to certain network topology contexts (all, core-only,
 edge-only...).  The goal is to provide network operators a clear,
 concise way of communicating their security requirements to vendors.

Jones Informational [Page 1] RFC 3871 Operational Security Requirements September 2004

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Goals. . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Motivation . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Definition of a Secure Network . . . . . . . . . . . . .  6
     1.5.  Intended Audience. . . . . . . . . . . . . . . . . . . .  6
     1.6.  Format . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.7.  Intended Use . . . . . . . . . . . . . . . . . . . . . .  7
     1.8.  Definitions. . . . . . . . . . . . . . . . . . . . . . .  7
 2.  Functional Requirements  . . . . . . . . . . . . . . . . . . . 11
     2.1.  Device Management Requirements . . . . . . . . . . . . . 11
           2.1.1.   Support Secure Channels For Management. . . . . 11
     2.2.  In-Band Management Requirements. . . . . . . . . . . . . 12
           2.2.1.   Use Cryptographic Algorithms Subject To
                    Open Review . . . . . . . . . . . . . . . . . . 12
           2.2.2.   Use Strong Cryptography . . . . . . . . . . . . 13
           2.2.3.   Use Protocols Subject To Open Review For
                    Management. . . . . . . . . . . . . . . . . . . 14
           2.2.4.   Allow Selection of Cryptographic Parameters . . 15
           2.2.5.   Management Functions Should Have Increased
                    Priority. . . . . . . . . . . . . . . . . . . . 16
     2.3.  Out-of-Band (OoB) Management Requirements  . . . . . . . 16
           2.3.1.   Support a 'Console' Interface . . . . . . . . . 17
           2.3.2.   'Console' Communication Profile Must Support
                    Reset . . . . . . . . . . . . . . . . . . . . . 19
           2.3.3.   'Console' Requires Minimal Functionality of
                    Attached Devices. . . . . . . . . . . . . . . . 19
           2.3.4.   'Console' Supports Fall-back Authentication . . 20
           2.3.5.   Support Separate Management Plane IP
                    Interfaces. . . . . . . . . . . . . . . . . . . 21
           2.3.6.   No Forwarding Between Management Plane And Other
                    Interfaces. . . . . . . . . . . . . . . . . . . 21
     2.4.  Configuration and Management Interface Requirements. . . 22
           2.4.1.   'CLI' Provides Access to All Configuration and
                    Management Functions. . . . . . . . . . . . . . 22
           2.4.2.   'CLI' Supports Scripting of Configuration . . . 23
           2.4.3.   'CLI' Supports Management Over 'Slow' Links . . 24
           2.4.4.   'CLI' Supports Idle Session Timeout . . . . . . 25
           2.4.5.   Support Software Installation . . . . . . . . . 25
           2.4.6.   Support Remote Configuration Backup . . . . . . 27
           2.4.7.   Support Remote Configuration Restore. . . . . . 27
           2.4.8.   Support Text Configuration Files. . . . . . . . 28
     2.5.  IP Stack Requirements. . . . . . . . . . . . . . . . . . 29
           2.5.1.   Ability to Identify All Listening Services. . . 29
           2.5.2.   Ability to Disable Any and All Services . . . . 30

Jones Informational [Page 2] RFC 3871 Operational Security Requirements September 2004

           2.5.3.   Ability to Control Service Bindings for
                    Listening Services. . . . . . . . . . . . . . . 30
           2.5.4.   Ability to Control Service Source Addresses . . 31
           2.5.5.   Support Automatic Anti-spoofing for
                    Single-Homed Networks . . . . . . . . . . . . . 32
           2.5.6.   Support Automatic Discarding Of Bogons and
                    Martians. . . . . . . . . . . . . . . . . . . . 33
           2.5.7.   Support Counters For Dropped Packets. . . . . . 34
     2.6.  Rate Limiting Requirements . . . . . . . . . . . . . . . 35
           2.6.1.   Support Rate Limiting . . . . . . . . . . . . . 35
           2.6.2.   Support Directional Application Of Rate
                    Limiting Per Interface. . . . . . . . . . . . . 36
           2.6.3.   Support Rate Limiting Based on State. . . . . . 36
     2.7.  Basic Filtering Capabilities . . . . . . . . . . . . . . 37
           2.7.1.   Ability to Filter Traffic . . . . . . . . . . . 37
           2.7.2.   Ability to Filter Traffic TO the Device . . . . 37
           2.7.3.   Ability to Filter Traffic THROUGH the Device. . 38
           2.7.4.   Ability to Filter Without Significant
                    Performance Degradation . . . . . . . . . . . . 38
           2.7.5.   Support Route Filtering . . . . . . . . . . . . 39
           2.7.6.   Ability to Specify Filter Actions . . . . . . . 40
           2.7.7.   Ability to Log Filter Actions . . . . . . . . . 40
     2.8.  Packet Filtering Criteria. . . . . . . . . . . . . . . . 41
           2.8.1.   Ability to Filter on Protocols. . . . . . . . . 41
           2.8.2.   Ability to Filter on Addresses. . . . . . . . . 42
           2.8.3.   Ability to Filter on Protocol Header Fields . . 42
           2.8.4.   Ability to Filter Inbound and Outbound. . . . . 43
     2.9.  Packet Filtering Counter Requirements. . . . . . . . . . 43
           2.9.1.   Ability to Accurately Count Filter Hits . . . . 43
           2.9.2.   Ability to Display Filter Counters. . . . . . . 44
           2.9.3.   Ability to Display Filter Counters per Rule . . 45
           2.9.4.   Ability to Display Filter Counters per Filter
                    Application . . . . . . . . . . . . . . . . . . 45
           2.9.5.   Ability to Reset Filter Counters. . . . . . . . 46
           2.9.6.   Filter Counters Must Be Accurate. . . . . . . . 47
     2.10. Other Packet Filtering Requirements  . . . . . . . . . . 47
           2.10.1.  Ability to Specify Filter Log Granularity . . . 47
     2.11. Event Logging Requirements . . . . . . . . . . . . . . . 48
           2.11.1.  Logging Facility Uses Protocols Subject To
                    Open Review . . . . . . . . . . . . . . . . . . 48
           2.11.2.  Logs Sent To Remote Servers . . . . . . . . . . 49
           2.11.3.  Ability to Select Reliable Delivery . . . . . . 49
           2.11.4.  Ability to Log Locally. . . . . . . . . . . . . 50
           2.11.5.  Ability to Maintain Accurate System Time. . . . 50
           2.11.6.  Display Timezone And UTC Offset . . . . . . . . 51
           2.11.7.  Default Timezone Should Be UTC. . . . . . . . . 52
           2.11.8.  Logs Must Be Timestamped. . . . . . . . . . . . 52
           2.11.9.  Logs Contain Untranslated IP Addresses. . . . . 53

Jones Informational [Page 3] RFC 3871 Operational Security Requirements September 2004

           2.11.10. Logs Contain Records Of Security Events . . . . 54
           2.11.11. Logs Do Not Contain Passwords . . . . . . . . . 55
     2.12. Authentication, Authorization, and Accounting (AAA)
           Requirements . . . . . . . . . . . . . . . . . . . . . . 55
           2.12.1.  Authenticate All User Access. . . . . . . . . . 55
           2.12.2.  Support Authentication of Individual Users. . . 56
           2.12.3.  Support Simultaneous Connections. . . . . . . . 56
           2.12.4.  Ability to Disable All Local Accounts . . . . . 57
           2.12.5.  Support Centralized User Authentication
                    Methods . . . . . . . . . . . . . . . . . . . . 57
           2.12.6.  Support Local User Authentication Method. . . . 58
           2.12.7.  Support Configuration of Order of
                    Authentication Methods  . . . . . . . . . . . . 59
           2.12.8.  Ability To Authenticate Without Plaintext
                    Passwords . . . . . . . . . . . . . . . . . . . 59
           2.12.9.  No Default Passwords. . . . . . . . . . . . . . 60
           2.12.10. Passwords Must Be Explicitly Configured Prior
                    To Use. . . . . . . . . . . . . . . . . . . . . 60
           2.12.11. Ability to Define Privilege Levels. . . . . . . 61
           2.12.12. Ability to Assign Privilege Levels to Users . . 62
           2.12.13. Default Privilege Level Must Be 'None'. . . . . 62
           2.12.14. Change in Privilege Levels Requires
                    Re-Authentication . . . . . . . . . . . . . . . 63
           2.12.15. Support Recovery Of Privileged Access . . . . . 64
     2.13. Layer 2 Devices Must Meet Higher Layer Requirements. . . 65
     2.14. Security Features Must Not Cause Operational Problems. . 65
     2.15. Security Features Should Have Minimal Performance
           Impact . . . . . . . . . . . . . . . . . . . . . . . . . 66
 3.  Documentation Requirements . . . . . . . . . . . . . . . . . . 67
     3.1.  Identify Services That May Be Listening. . . . . . . . . 67
     3.2.  Document Service Defaults. . . . . . . . . . . . . . . . 67
     3.3.  Document Service Activation Process. . . . . . . . . . . 68
     3.4.  Document Command Line Interface. . . . . . . . . . . . . 68
     3.5.  'Console' Default Communication Profile Documented . . . 69
 4.  Assurance Requirements . . . . . . . . . . . . . . . . . . . . 69
     4.1.  Identify Origin of IP Stack. . . . . . . . . . . . . . . 70
     4.2.  Identify Origin of Operating System. . . . . . . . . . . 70
 5.  Security Considerations . .  . . . . . . . . . . . . . . . . . 71
 6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
     6.1.  Normative References . . . . . . . . . . . . . . . . . . 71
     6.2.  Informative References . . . . . . . . . . . . . . . . . 74
 Appendices
 A.  Requirement Profiles . . . . . . . . . . . . . . . . . . . . . 75
     A.1.  Minimum Requirements Profile . . . . . . . . . . . . . . 75
     A.2.  Layer 3 Network Edge Profile . . . . . . . . . . . . . . 78
 B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 79
 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 80
 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 81

Jones Informational [Page 4] RFC 3871 Operational Security Requirements September 2004

1. Introduction

1.1. Goals

 This document defines a list of operational security requirements for
 the infrastructure of large IP networks (routers and switches).  The
 goal is to provide network operators a clear, concise way of
 communicating their security requirements to equipment vendors.

1.2. Motivation

 Network operators need tools to ensure that they are able to manage
 their networks securely and to insure that they maintain the ability
 to provide service to their customers.  Some of the threats are
 outlined in section 3.2 of [RFC2196].  This document enumerates
 features which are required to implement many of the policies and
 procedures suggested by [RFC2196] in the context of the
 infrastructure of large IP-based networks.  Also see [RFC3013].

1.3. Scope

 The scope of these requirements is intended to cover the managed
 infrastructure of large ISP IP networks (e.g., routers and switches).
 Certain groups (or "profiles", see below) apply only in specific
 situations (e.g., edge-only).
 The following are explicitly out of scope:
 o  general purpose hosts that do not transit traffic including
    infrastructure hosts such as name/time/log/AAA servers, etc.,
 o  unmanaged devices,
 o  customer managed devices (e.g., firewalls, Intrusion Detection
    System, dedicated VPN devices, etc.),
 o  SOHO (Small Office, Home Office) devices (e.g., personal
    firewalls, Wireless Access Points, Cable Modems, etc.),
 o  confidentiality of customer data,
 o  integrity of customer data,
 o  physical security.
 This means that while the requirements in the minimum profile (and
 others) may apply, additional requirements have not be added to
 account for their unique needs.

Jones Informational [Page 5] RFC 3871 Operational Security Requirements September 2004

 While the examples given are written with IPv4 in mind, most of the
 requirements are general enough to apply to IPv6.

1.4. Definition of a Secure Network

 For the purposes of this document, a secure network is one in which:
 o  The network keeps passing legitimate customer traffic
    (availability).
 o  Traffic goes where it is supposed to go, and only where it is
    supposed to go (availability, confidentiality).
 o  The network elements remain manageable (availability).
 o  Only authorized users can manage network elements (authorization).
 o  There is a record of all security related events (accountability).
 o  The network operator has the necessary tools to detect and respond
    to illegitimate traffic.

1.5. Intended Audience

 There are two intended audiences: the network operator who selects,
 purchases, and operates IP network equipment, and the vendors who
 create them.

1.6. Format

 The individual requirements are listed in the three sections below.
 o  Section 2 lists functional requirements.
 o  Section 3 lists documentation requirements.
 o  Section 4 lists assurance requirements.
 Within these areas, requirements are grouped in major functional
 areas (e.g., logging, authentication, filtering, etc.)
 Each requirement has the following subsections:
 o  Requirement (what)
 o  Justification (why)
 o  Examples (how)

Jones Informational [Page 6] RFC 3871 Operational Security Requirements September 2004

 o  Warnings (if applicable)
 The requirement describes a policy to be supported by the device.
 The justification tells why and in what context the requirement is
 important.  The examples section is intended to give examples of
 implementations that may meet the requirement.  Examples cite
 technology and standards current at the time of this writing.  See
 [RFC3631].  It is expected that the choice of implementations to meet
 the requirements will change over time.  The warnings list
 operational concerns, deviation from standards, caveats, etc.
 Security requirements will vary across different device types and
 different organizations, depending on policy and other factors.  A
 desired feature in one environment may be a requirement in another.
 Classifications must be made according to local need.
 In order to assist in classification, Appendix A defines several
 requirement "profiles" for different types of devices.  Profiles are
 concise lists of requirements that apply to certain classes of
 devices.  The profiles in this document should be reviewed to
 determine if they are appropriate to the local environment.

1.7. Intended Use

 It is anticipated that the requirements in this document will be used
 for the following purposes:
 o  as a checklist when evaluating networked products,
 o  to create profiles of different subsets of the requirements which
    describe the needs of different devices, organizations, and
    operating environments,
 o  to assist operators in clearly communicating their security
    requirements,
 o  as high level guidance for the creation of detailed test plans.

1.8. Definitions

 RFC 2119 Keywords
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    in this document are to be interpreted as described in [RFC2119].

Jones Informational [Page 7] RFC 3871 Operational Security Requirements September 2004

    The use of the RFC 2119 keywords is an attempt, by the editor, to
    assign the correct requirement levels ("MUST", "SHOULD",
    "MAY"...).  It must be noted that different organizations,
    operational environments, policies and legal environments will
    generate different requirement levels.  Operators and vendors
    should carefully consider the individual requirements listed here
    in their own context.  One size does not fit all.
 Bogon.
    A "Bogon" (plural: "bogons") is a packet with an IP source address
    in an address block not yet allocated by IANA or the Regional
    Internet Registries (ARIN, RIPE, APNIC...) as well as all
    addresses reserved for private or special use by RFCs.  See
    [RFC3330] and [RFC1918].
 CLI.
    Several requirements refer to a Command Line Interface (CLI).
    While this refers at present to a classic text oriented command
    interface, it is not intended to preclude other mechanisms which
    may meet all the requirements that reference "CLI".
 Console.
    Several requirements refer to a "Console".  The model for this is
    the classic RS232 serial port which has, for the past 30 or more
    years, provided a simple, stable, reliable, well-understood and
    nearly ubiquitous management interface to network devices.  Again,
    these requirements are intended primarily to codify the benefits
    provided by that venerable interface, not to preclude other
    mechanisms that meet all the same requirements.
 Filter.
    In this document, a "filter" is defined as a group of one or more
    rules where each rule specifies one or more match criteria as
    specified in Section 2.8.
 In-Band management.
    "In-Band management" is defined as any management done over the
    same channels and interfaces used for user/customer data.
    Examples would include using SSH for management via customer or
    Internet facing network interfaces.

Jones Informational [Page 8] RFC 3871 Operational Security Requirements September 2004

 High Resolution Time.
    "High resolution time" is defined in this document as "time having
    a resolution greater than one second" (e.g., milliseconds).
 IP.
    Unless otherwise indicated, "IP" refers to IPv4.
 Management.
    This document uses a broad definition of the term "management".
    In this document, "management" refers to any authorized
    interaction with the device intended to change its operational
    state or configuration.  Data/Forwarding plane functions (e.g.,
    the transit of customer traffic) are not considered management.
    Control plane functions such as routing, signaling and link
    management protocols and management plane functions such as remote
    access, configuration and authentication are considered to be
    management.
 Martian.
    Per [RFC1208] "Martian: Humorous term applied to packets that turn
    up unexpectedly on the wrong network because of bogus routing
    entries.  Also used as a name for a packet which has an altogether
    bogus (non-registered or ill-formed) Internet address."  For the
    purposes of this document Martians are defined as "packets having
    a source address that, by application of the current forwarding
    tables, would not have its return traffic routed back to the
    sender."  "Spoofed packets" are a common source of martians.
    Note that in some cases, the traffic may be asymmetric, and a
    simple forwarding table check might produce false positives.  See
    [RFC3704]
 Out-of-Band (OoB) management.
    "Out-of-Band management" is defined as any management done over
    channels and interfaces that are separate from those used for
    user/customer data.  Examples would include a serial console
    interface or a network interface connected to a dedicated
    management network that is not used to carry customer traffic.

Jones Informational [Page 9] RFC 3871 Operational Security Requirements September 2004

 Open Review.
    "Open review" refers to processes designed to generate public
    discussion and review of proposed technical solutions such as data
    communications protocols and cryptographic algorithms with the
    goals of improving and building confidence in the final solutions.
    For the purposes of this document "open review" is defined by
    [RFC2026].  All standards track documents are considered to have
    been through an open review process.
    It should be noted that organizations may have local requirements
    that define what they view as acceptable "open review".  For
    example, they may be required to adhere to certain national or
    international standards.  Such modifications of the definition of
    the term "open review", while important, are considered local
    issues that should be discussed between the organization and the
    vendor.
    It should also be noted that section 7 of [RFC2026] permits
    standards track documents to incorporate other "external standards
    and specifications".
 Service.
    A number of requirements refer to "services".  For the purposes of
    this document a "service" is defined as "any process or protocol
    running in the control or management planes to which non-transit
    packets may be delivered".  Examples might include an SSH server,
    a BGP process or an NTP server.  It would also include the
    transport, network and link layer protocols since, for example, a
    TCP packet addressed to a port on which no service is listening
    will be "delivered" to the IP stack, and possibly result in an
    ICMP message being sent back.
 Secure Channel.
    A "secure channel" is a mechanism that ensures end-to-end
    integrity and confidentiality of communications.  Examples include
    TLS [RFC2246] and IPsec [RFC2401].  Connecting a terminal to a
    console port using physically secure, shielded cable would provide
    confidentiality but possibly not integrity.
 Single-Homed Network.
    A "single-homed network" is defined as one for which
  • There is only one upstream connection

Jones Informational [Page 10] RFC 3871 Operational Security Requirements September 2004

  • Routing is symmetric.
    See [RFC3704] for a discussion of related issues and mechanisms
    for multihomed networks.
 Spoofed Packet.
    A "spoofed packet" is defined as a packet that has a source
    address that does not correspond to any address assigned to the
    system which sent the packet.  Spoofed packets are often "bogons"
    or "martians".

2. Functional Requirements

 The requirements in this section are intended to list testable,
 functional requirements that are needed to operate devices securely.

2.1. Device Management Requirements

2.1.1. Support Secure Channels For Management

 Requirement.
    The device MUST provide mechanisms to ensure end-to-end integrity
    and confidentiality for all network traffic and protocols used to
    support management functions.  This MUST include at least
    protocols used for configuration, monitoring, configuration backup
    and restore, logging, time synchronization, authentication, and
    routing.
 Justification.
    Integrity protection is required to ensure that unauthorized users
    cannot manage the device or alter log data or the results of
    management commands.  Confidentiality is required so that
    unauthorized users cannot view sensitive information, such as
    keys, passwords, or the identity of users.
 Examples.
    See [RFC3631] for a current list of mechanisms that can be used to
    support secure management.
    Later sections list requirements for supporting in-band management
    (Section 2.2)  and out-of-band management (Section 2.3) as well as
    trade-offs that must be weighed in considering which is
    appropriate to a given situation.

Jones Informational [Page 11] RFC 3871 Operational Security Requirements September 2004

 Warnings.
    None.

2.2. In-Band Management Requirements

 This section lists security requirements that support secure in-band
 management.  In-band  management has the advantage of lower cost (no
 extra interfaces or lines), but has significant security
 disadvantages:
 o  Saturation of customer lines or interfaces can make the device
    unmanageable unless out-of-band management resources have been
    reserved.
 o  Since public interfaces/channels are used, it is possible for
    attackers to directly address and reach the device and to attempt
    management functions.
 o  In-band management traffic on public interfaces may be
    intercepted, however this would typically require a significant
    compromise in the routing system.
 o  Public interfaces used for in-band management may become
    unavailable due to bugs (e.g., buffer overflows being exploited)
    while out-of-band interfaces (such as a serial console device)
    remain available.
 There are many situations where in-band management makes sense, is
 used, and/or is the only option.  The following requirements are
 meant to provide means of securing in-band management traffic.

2.2.1. Use Cryptographic Algorithms Subject To Open Review

 Requirement.
    If cryptography is used to provide secure management functions,
    then there MUST be an option to use algorithms that are subject to
    "open review" as defined in Section 1.8 to provide these
    functions.  These SHOULD be used by default.  The device MAY
    optionally support algorithms that are not open to review.
 Justification.
    Cryptographic algorithms that have not been subjected to
    widespread, extended public/peer review are more likely to have
    undiscovered weaknesses or flaws than open standards and publicly
    reviewed algorithms.  Network operators may have need or desire to

Jones Informational [Page 12] RFC 3871 Operational Security Requirements September 2004

    use non-open cryptographic algorithms.  They should be allowed to
    evaluate the trade-offs and make an informed choice between open
    and non-open cryptography.  See [Schneier] for further discussion.
 Examples.
    The following are some algorithms that satisfy the requirement at
    the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998]
    for applications requiring symmetric encryption; RSA [RFC3447] and
    Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring
    key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications
    requiring message verification.
 Warnings.
    This list is not exhaustive.  Other strong, well-reviewed
    algorithms may meet the requirement.  The dynamic nature of the
    field means that what is good enough today may not be in the
    future.
    Open review is necessary but not sufficient.  The strength of the
    algorithm and key length must also be considered.  For example,
    56-bit DES meets the open review requirement, but is today
    considered too weak and is therefore not recommended.

2.2.2. Use Strong Cryptography

 Requirement.
    If cryptography is used to meet the secure management channel
    requirements, then the key lengths and algorithms SHOULD be
    "strong".
 Justification.
    Short keys and weak algorithms threaten the confidentiality and
    integrity of communications.
 Examples.
    The following algorithms satisfy the requirement at the time of
    writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] for
    applications requiring symmetric encryption; RSA [RFC3447] and
    Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring
    key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications
    requiring message verification.

Jones Informational [Page 13] RFC 3871 Operational Security Requirements September 2004

    Note that for *new protocols* [RFC3631]  says the following:
    "Simple keyed hashes based on MD5 [RFC1321], such as that used in
    the BGP session security mechanism [RFC2385], are especially to be
    avoided in new protocols, given the hints of weakness in MD5."
    While use of such hashes in deployed products and protocols is
    preferable to a complete lack of integrity and authentication
    checks, this document concurs with the recommendation that new
    products and protocols strongly consider alternatives.
 Warnings.
    This list is not exhaustive.  Other strong, well-reviewed
    algorithms may meet the requirement.  The dynamic nature of the
    field means that what is good enough today may not be in the
    future.
    Strength is relative.  Long keys and strong algorithms are
    intended to increase the work factor required to compromise the
    security of the data protected.  Over time, as processing power
    increases, the security provided by a given algorithm and key
    length will degrade.  The definition of "Strong" must be
    constantly reevaluated.
    There may be legal issues governing the use of cryptography and
    the strength of cryptography used.
    This document explicitly does not attempt to make any
    authoritative statement about what key lengths constitute "strong"
    cryptography.  See  [RFC3562] and [RFC3766] for help in
    determining appropriate key lengths.  Also see [Schneier] chapter
    7 for a discussion of key lengths.

2.2.3. Use Protocols Subject To Open Review For Management

 Requirement.
    If cryptography is used to provide secure management channels,
    then its use MUST be supported in protocols that are subject to
    "open review" as defined in Section 1.8.  These SHOULD be used by
    default.  The device MAY optionally support the use of
    cryptography in protocols that are not open to review.

Jones Informational [Page 14] RFC 3871 Operational Security Requirements September 2004

 Justification.
    Protocols that have not been subjected to widespread, extended
    public/peer review are more likely to have undiscovered weaknesses
    or flaws than open standards and publicly reviewed protocols
    Network operators may have need or desire to use non-open
    protocols They should be allowed to evaluate the trade-offs and
    make an informed choice between open and non-open protocols.
 Examples.
    See TLS [RFC2246] and IPsec [RFC2401].
 Warnings.
    Note that open review is necessary but may not be sufficient.  It
    is perfectly possible for an openly reviewed protocol to misuse
    (or not use) cryptography.

2.2.4. Allow Selection of Cryptographic Parameters

 Requirement.
    The device SHOULD allow the operator to select cryptographic
    parameters.  This SHOULD include key lengths and algorithms.
 Justification.
    Cryptography using certain algorithms and key lengths may be
    considered "strong" at one point in time, but "weak" at another.
    The constant increase in compute power continually reduces the
    time needed to break cryptography of a certain strength.
    Weaknesses may be discovered in algorithms.  The ability to select
    a different algorithm is a useful tool for maintaining security in
    the face of such discoveries.
 Examples.
    56-bit DES was once considered secure.  In 1998 it was cracked by
    custom built machine in under 3 days.  The ability to select
    algorithms and key lengths would give the operator options
    (different algorithms, longer keys) in the face of such
    developments.
 Warnings.
    None.

Jones Informational [Page 15] RFC 3871 Operational Security Requirements September 2004

2.2.5. Management Functions Should Have Increased Priority

 Requirement.
    Management functions SHOULD be processed at higher priority than
    non-management traffic.  This SHOULD include ingress, egress,
    internal transmission, and processing.  This SHOULD include at
    least protocols used for configuration, monitoring, configuration
    backup, logging, time synchronization, authentication, and
    routing.
 Justification.
    Certain attacks (and normal operation) can cause resource
    saturation such as link congestion, memory exhaustion or CPU
    overload.  In these cases it is important that management
    functions be prioritized to ensure that operators have the tools
    needed to recover from the attack.
 Examples.
    Imagine a service provider with 1,000,000 DSL subscribers, most of
    whom have no firewall protection.  Imagine that a large portion of
    these subscribers machines were infected with a new worm that
    enabled them to be used in coordinated fashion as part of large
    denial of service attack that involved flooding.  It is entirely
    possible that without prioritization such an attack would cause
    link congestion resulting in routing adjacencies being lost.  A
    DoS attack against hosts has just become a DoS attack against the
    network.
 Warnings.
    Prioritization is not a panacea.  Routing update packets may not
    make it across a saturated link.  This requirement simply says
    that the device should prioritize management functions within its
    scope of control (e.g., ingress, egress, internal transit,
    processing).  To the extent that this is done across an entire
    network, the overall effect will be to ensure that the network
    remains manageable.

2.3. Out-of-Band (OoB) Management Requirements

 See Section 2.2 for a discussion of the advantages and disadvantages
 of In-band vs. Out-of-Band management.

Jones Informational [Page 16] RFC 3871 Operational Security Requirements September 2004

 These requirements assume two different possible Out-of-Band
 topologies:
 o  serial line (or equivalent) console connections using a CLI,
 o  network interfaces connected to a separate network dedicated to
    management.
 The following assumptions are made about out-of-band management:
 o  The out-of-band management network is secure.
 o  Communications beyond the management interface (e.g., console
    port, management network interface) is secure.
 o  There is no need for encryption of communication on out-of-band
    management interfaces, (e.g., on a serial connection between a
    terminal server and a device's console port).
 o  Security measures are in place to prevent unauthorized physical
    access.
 Even if these assumptions hold it would be wise, as an application of
 defense-in-depth, to apply the in-band requirements (e.g.,
 encryption) to out-of-band interfaces.

2.3.1. Support a 'Console' Interface

 Requirement.
    The device MUST support complete configuration and management via
    a 'console' interface that functions independently from the
    forwarding and IP control planes.
 Justification.
    There are times when it is operationally necessary to be able to
    immediately and easily access a device for management or
    configuration, even when the network is unavailable, routing and
    network interfaces are incorrectly configured, the IP stack and/or
    operating system may not be working (or may be vulnerable to
    recently discovered exploits that make their use impossible/
    inadvisable), or when high bandwidth paths to the device are
    unavailable.  In such situations, a console interface can provide
    a way to manage and configure the device.

Jones Informational [Page 17] RFC 3871 Operational Security Requirements September 2004

 Examples.
    An RS232 (EIA232) interface that provides the capability to load
    new versions of the system software and to perform configuration
    via a command line interface.  RS232 interfaces are ubiquitous and
    well understood.
    A simple embedded device that provides management and
    configuration access via an Ethernet or USB interface.
    As of this writing, RS232 is still strongly recommended as it
    provides the following benefits:
  • Simplicity. RS232 is far simpler than the alternatives. It is

simply a hardware specification. By contrast an Ethernet based

       solution might require an ethernet interface, an operating
       system, an IP stack and an HTTP server all to be functioning
       and properly configured.
  • Proven. RS232 has more than 30 years of use.
  • Well-Understood. Operators have a great deal of experience

with RS232.

  • Availability. It works even in the presence of network

failure.

  • Ubiquity. It is very widely deployed in mid to high end

network infrastructure.

  • Low-Cost. The cost of adding a RS232 port to a device is

small.

  • CLI-Friendly. An RS232 interface and a CLI are sufficient in

most cases to manage a device. No additional software is

       required.
  • Integrated. Operators have many solutions (terminal servers,

etc.) currently deployed to support management via RS232.

       While other interfaces may be supplied, the properties listed
       above should be considered.  Interfaces not having these
       properties may present challenges in terms of ease of use,
       integration or adoption.  Problems in any of these areas could
       have negative security impacts, particularly in situations
       where the console must be used to quickly respond to incidents.

Jones Informational [Page 18] RFC 3871 Operational Security Requirements September 2004

 Warnings.
    It is common practice is to connect RS232 ports to terminal
    servers that permit networked access for convenience.  This
    increases the potential security exposure of mechanisms available
    only via RS232 ports.  For example, a password recovery mechanism
    that is available only via RS232 might give a remote hacker to
    completely reconfigure a router.  While operational procedures are
    beyond the scope of this document, it is important to note here
    that strong attention should be given to policies, procedures,
    access mechanisms and physical security governing access to
    console ports.

2.3.2. 'Console' Communication Profile Must Support Reset

 Requirement.
    There MUST be a method defined and published for returning the
    console communication parameters to their default settings.  This
    method must not require the current settings to be known.
 Justification.
    Having to guess at communications settings can waste time.  In a
    crisis situation, the operator may need to get on the console of a
    device quickly.
 Examples.
    One method might be to send a break on a serial line.
 Warnings.
    None.

2.3.3. 'Console' Requires Minimal Functionality of Attached Devices

 Requirement.
    The use of the 'console' interface MUST NOT require proprietary
    devices, protocol extensions or specific client software.

Jones Informational [Page 19] RFC 3871 Operational Security Requirements September 2004

 Justification.
    The purpose of having the console interface is to have a
    management interface that can be made to work quickly at all
    times.  Requiring complex or nonstandard behavior on the part of
    attached devices reduces the likelihood that the console will work
    without hassles.
 Examples.
    If the console is supplied via an RS232 interface, then it should
    function with an attached device that only implements a "dumb"
    terminal.  Support of "advanced" terminal features/types should be
    optional.
 Warnings.
    None.

2.3.4. 'Console' Supports Fall-back Authentication

 Requirement.
    The 'console' SHOULD support an authentication mechanism which
    does not require functional IP or depend on external services.
    This authentication mechanism MAY be disabled until a failure of
    other preferred mechanisms is detected.
 Justification.
    It does little good to have a console interface on a device if you
    cannot get into the device with it when the network is not
    working.
 Examples.
    Some devices which use TACACS or RADIUS for authentication will
    fall back to a local account if the TACACS or RADIUS server does
    not reply to an authentication request.
 Warnings.
    This requirement represents a trade-off between being able to
    manage the device (functionality) and security.  There are many
    ways to implement this which would provide reduced security for
    the device, (e.g., a back door for unauthorized access).  Local
    policy should be consulted to determine if "fail open" or "fail

Jones Informational [Page 20] RFC 3871 Operational Security Requirements September 2004

    closed" is the correct stance.  The implications of "fail closed"
    (e.g., not being able to manage a device) should be fully
    considered.
    If the fall-back mechanism is disabled, it is important that the
    failure of IP based authentication mechanism be reliably detected
    and the fall-back mechanism automatically enabled...otherwise the
    operator may be left with no means to authenticate.

2.3.5. Support Separate Management Plane IP Interfaces

 Requirement.
    The device MAY provide designated network interface(s) that are
    used for management plane traffic.
 Justification.
    A separate management plane interface allows management traffic to
    be segregated from other traffic (data/forwarding plane, control
    plane).  This reduces the risk that unauthorized individuals will
    be able to observe management traffic and/or compromise the
    device.
    This requirement applies in situations where a separate OoB
    management network exists.
 Examples.
    Ethernet port dedicated to management and isolated from customer
    traffic satisfies this requirement.
 Warnings.
    The use of this type of interface depends on proper functioning of
    both the operating system and the IP stack, as well as good, known
    configuration at least on the portions of the device dedicated to
    management.

2.3.6. No Forwarding Between Management Plane And Other Interfaces

 Requirement.
    If the device implements separate network interface(s) for the
    management plane per Section 2.3.5 then the device MUST NOT
    forward traffic between the management plane and non-management
    plane interfaces.

Jones Informational [Page 21] RFC 3871 Operational Security Requirements September 2004

 Justification.
    This prevents the flow, intentional or unintentional, of
    management traffic to/from places that it should not be
    originating/terminating (e.g., anything beyond the customer-facing
    interfaces).
 Examples.
    Implementing separate forwarding tables for management plane and
    non-management plane interfaces that do not propagate routes to
    each other satisfies this requirement.
 Warnings.
    None.

2.4. Configuration and Management Interface Requirements

 This section lists requirements that support secure device
 configuration and management methods.  In most cases, this currently
 involves some sort of command line interface (CLI) and configuration
 files.  It may be possible to meet these requirements with other
 mechanisms, for instance SNMP or a script-able HTML interface that
 provides full access to management and configuration functions.  In
 the future, there may be others (e.g., XML based configuration).

2.4.1. 'CLI' Provides Access to All Configuration and Management

       Functions
 Requirement.
    The Command Line Interface (CLI) or equivalent MUST allow complete
    access to all configuration and management functions.  The CLI
    MUST be supported on the console (see Section 2.3.1) and SHOULD be
    supported on all other interfaces used for management.
 Justification.
    The CLI (or equivalent) is needed to provide the ability to do
    reliable, fast, direct, local management and monitoring of a
    device.  It is particularly useful in situations where it is not
    possible to manage and monitor the device in-band via "normal"
    means (e.g., SSH or SNMP [RFC3410], [RFC3411]) that depend on
    functional networking.  Such situations often occur during
    security incidents such as bandwidth-based denial of service
    attacks.

Jones Informational [Page 22] RFC 3871 Operational Security Requirements September 2004

 Examples.
    Examples of configuration include setting interface addresses,
    defining and applying filters, configuring logging and
    authentication, etc.  Examples of management functions include
    displaying dynamic state information such as CPU load, memory
    utilization, packet processing statistics, etc.
 Warnings.
    None.

2.4.2. 'CLI' Supports Scripting of Configuration

 Requirement.
    The CLI or equivalent MUST support external scripting of
    configuration functions.  This CLI SHOULD support the same command
    set and syntax as that in Section 2.4.1.
 Justification.
    During the handling of security incidents, it is often necessary
    to quickly make configuration changes on large numbers of devices.
    Doing so manually is error prone and slow.  Vendor supplied
    management solutions do not always foresee or address the type or
    scale of solutions that are required.  The ability to script
    provides a solution to these problems.
 Examples.
    Example uses of scripting include: tracking an attack across a
    large network, updating authentication parameters, updating
    logging parameters, updating filters, configuration fetching/
    auditing, etc.  Some languages that are currently used for
    scripting include expect, Perl and TCL.
 Warnings.
    Some properties of the command language that enhance the ability
    to script are: simplicity, regularity and consistency.  Some
    implementations that would make scripting difficult or impossible
    include: "text menu" style interfaces (e.g., "curses" on UNIX) or
    a hard-coded GUI interfaces (e.g., a native Windows or Macintosh
    GUI application) that communicate using a proprietary or
    undocumented protocol not based on a CLI.

Jones Informational [Page 23] RFC 3871 Operational Security Requirements September 2004

2.4.3. 'CLI' Supports Management Over 'Slow' Links

 Requirement.
    The device MUST support a command line interface (CLI) or
    equivalent mechanism that works over low bandwidth connections.
 Justification.
 There are situations where high bandwidth for management is not
 available, for example when in-band connections are overloaded during
 an attack or when low-bandwidth, out-of-band connections such as
 modems must be used.  It is often under these conditions that it is
 most crucial to be able to perform management and configuration
 functions.
 Examples.
    The network is down.  The network engineer just disabled routing
    by mistake on the sole gateway router in a remote unmanned data
    center.  The only access to the device is over a modem connected
    to a console port.  The data center customers are starting to call
    the support line.  The GUI management interface is redrawing the
    screen multiple times...slowly... at 9600bps.
    One mechanism that supports operation over slow links is the
    ability to apply filters to the output of CLI commands which have
    potentially large output.  This may be implemented with something
    similar to the UNIX pipe facility and "grep" command.
    For example,
       cat largefile.txt | grep interesting-string
    Another is the ability to "page" through large command output,
    e.g., the UNIX "more" command:
    For example,
       cat largefile.txt | more
 Warnings.
    One consequence of this requirement may be that requiring a GUI
    interface for management is unacceptable unless it can be shown to
    work acceptably over slow links.

Jones Informational [Page 24] RFC 3871 Operational Security Requirements September 2004

2.4.4. 'CLI' Supports Idle Session Timeout

 Requirement.
    The command line interface (CLI) or equivalent mechanism MUST
    support a configurable idle timeout value.
 Justification.
    Network administrators go to lunch.  They leave themselves logged
    in with administrative privileges.  They forget to use screen-
    savers with password protection.  They do this while at
    conferences and in other public places.  This behavior presents
    opportunity for unauthorized access.  Idle timeouts reduce the
    window of exposure.
 Examples.
    The CLI may provide a configuration command that allows an idle
    timeout to be set.  If the operator does not enter commands for
    that amount of time, the login session will be automatically
    terminated.
 Warnings.
    None.

2.4.5. Support Software Installation

 Requirement.
    The device MUST provide a means to install new software versions.
    It MUST be possible to install new software while the device is
    disconnected from all public IP networks.  This MUST NOT rely on
    previous installation and/or configuration.  While new software
    MAY be loaded from writable media (disk, flash, etc.), the
    capability to load new software MUST depend only on non-writable
    media (ROM, etc.).  The installation procedures SHOULD support
    mechanisms to ensure reliability and integrity of data transfers.
 Justification.
  • Vulnerabilities are often discovered in the base software

(operating systems, etc.) shipped by vendors. Often mitigation of

    the risk presented by these vulnerabilities can only be
    accomplished by updates to the vendor supplied software (e.g., bug

Jones Informational [Page 25] RFC 3871 Operational Security Requirements September 2004

    fixes, new versions of code, etc.).  Without a mechanism to load
    new vendor supplied code, it may not be possible to mitigate the
    risk posed by these vulnerabilities.
  • It is also conceivable that malicious behavior on the part of

hackers or unintentional behaviors on the part of operators could

    cause software on devices to be corrupted or erased.  In these
    situations, it is necessary to have a means to (re)load software
    onto the device to restore correct functioning.
  • It is important to be able to load new software while disconnected

from all public IP networks because the device may be vulnerable

    to old attacks before the update is complete.
  • One has to assume that hackers, operators, etc. may erase or

corrupt all writable media (disks, flash, etc.). In such

    situations, it is necessary to be able to recover starting with
    only non-writable media (e.g., CD-ROM, a true ROM-based monitor).
  • System images may be corrupted in transit (from vendor to

customer, or during the loading process) or in storage (bit rot,

    defective media, etc.).  Failure to reliably load a new image, for
    example after a hacker deletes or corrupts the installed image,
    could result in extended loss of availability.
 Examples.
    The device could support booting into a simple ROM-based monitor
    that supported a set of commands sufficient to load new operating
    system code and configuration data from other devices.  The
    operating system and configuration might be loaded from:
 RS232. The device could support uploading new code via an RS232
    console port.
 CD-ROM. The device could support installing new code from a
    locally attached CD-ROM drive.
 NETWORK. The device could support installing new code via a
    network interface, assuming that (a) it is disconnected from all
    public networks and (b) the device can boot an OS and IP stack
    from some read-only media with sufficient capabilities to load new
    code  from the network.

Jones Informational [Page 26] RFC 3871 Operational Security Requirements September 2004

 FLASH. The device could support booting from flash memory cards.
    Simple mechanisms currently in use to protect the integrity of
    system images and data transfer include image checksums and simple
    serial file transfer protocols such as XMODEM and Kermit.
 Warnings.
    None.

2.4.6. Support Remote Configuration Backup

 Requirement.
    The device MUST provide a means to store the system configuration
    to a remote server.  The stored configuration MUST have sufficient
    information to restore the device to its operational state at the
    time the configuration is saved.  Stored versions of the
    configuration MAY be compressed using an algorithm which is
    subject to open review, as long as the fact is clearly identified
    and the compression can be disabled.  Sensitive information such
    as passwords that could be used to compromise the security of the
    device MAY be excluded from the saved configuration.
 Justification.
    Archived configurations are essential to enable auditing and
    recovery.
 Examples.
    Possible implementations include SCP, SFTP or FTP over a secure
    channel.  See Section 2.1.1 for requirements related to secure
    communication channels for management protocols and data.
 Warnings.
    The security of the remote server is assumed, with appropriate
    measures being outside the scope of this document.

2.4.7. Support Remote Configuration Restore

 Requirement.
    The device MUST provide a means to restore a configuration that
    was saved as described in Section 2.4.6.  The system MUST be
    restored to its operational state at the time the configuration
    was saved.

Jones Informational [Page 27] RFC 3871 Operational Security Requirements September 2004

 Justification.
    Restoration of archived configurations allows quick restoration of
    service following an outage (security related as well as from
    other causes).
 Examples.
    Configurations may be restored using SCP, SFTP or FTP over a
    secure channel.  See Section 2.1.1 for requirements related to
    secure communication channels for management protocols and data.
 Warnings.
    The security of the remote server is assumed, with appropriate
    measures being outside the scope of this document.
    Note that if passwords or other sensitive information are excluded
    from the saved copy of the configuration, as allowed by Section
    2.4.6, then the restore may not be complete.  The operator may
    have to set new passwords or supply other information that was not
    saved.

2.4.8. Support Text Configuration Files

 Requirement.
    The device MUST support display, backup and restore of system
    configuration in a simple well defined textual format.  The
    configuration MUST also be viewable as text on the device itself.
    It MUST NOT be necessary to use a proprietary program to view the
    configuration.
 Justification.
    Simple, well-defined textual configurations facilitate human
    understanding of the operational state of the device, enable off-
    line audits, and facilitate automation.  Requiring the use of a
    proprietary program to access the configuration inhibits these
    goals.
 Examples.
    A 7-bit ASCII configuration file that shows the current settings
    of the various configuration options would satisfy the
    requirement, as would a Unicode configuration or any other
    "textual" representation.  A structured binary format intended
    only for consumption by programs would not be acceptable.

Jones Informational [Page 28] RFC 3871 Operational Security Requirements September 2004

 Warnings.
    Offline copies of configurations should be well protected as they
    often contain sensitive information such as SNMP community
    strings, passwords, network blocks, customer information, etc.
    "Well defined" and "textual" are open to interpretation.  Clearly
    an ASCII configuration file with a regular, documented command
    oriented-syntax would meet the definition.  These are currently in
    wide use.  Future options, such as XML based configuration may
    meet the requirement.  Determining this will require evaluation
    against the justifications listed above.

2.5. IP Stack Requirements

2.5.1. Ability to Identify All Listening Services

 Requirement.
    The vendor MUST:
  • Provide a means to display all services that are listening for

network traffic directed at the device from any external

       source.
  • Display the addresses to which each service is bound.
  • Display the addresses assigned to each interface.
  • Display any and all port(s) on which the service is listing.
  • Include both open standard and vendor proprietary services.
 Justification.
    This information is necessary to enable a thorough assessment of
    the security risks associated with the operation of the device
    (e.g., "does this protocol allow complete management of the device
    without also requiring authentication, authorization, or
    accounting?").  The information also assists in determining what
    steps should be taken to mitigate risk (e.g., "should I turn this
    service off ?")

Jones Informational [Page 29] RFC 3871 Operational Security Requirements September 2004

 Examples.
    If the device is listening for SNMP traffic from any source
    directed to the IP addresses of any of its local interfaces, then
    this requirement could be met by the provision of a command which
    displays that fact.
 Warnings.
    None.

2.5.2. Ability to Disable Any and All Services

 Requirement.
    The device MUST provide a means to turn off any "services" (see
    Section 1.8).
 Justification.
    The ability to disable services for which there is no operational
    need will allow administrators to reduce the overall risk posed to
    the device.
 Examples.
    Processes that listen on TCP and UDP ports would be prime examples
    of services that it must be possible to disable.
 Warnings.
    None.

2.5.3. Ability to Control Service Bindings for Listening Services

 Requirement.
    The device MUST provide a means for the user to specify the
    bindings used for all listening services.  It MUST support binding
    to any address or net-block associated with any interface local to
    the device.  This must include addresses bound to physical or
    non-physical (e.g., loopback) interfaces.
 Justification.
    It is a common practice among operators to configure "loopback"
    pseudo-interfaces to use as the source and destination of
    management traffic.  These are preferred to physical interfaces

Jones Informational [Page 30] RFC 3871 Operational Security Requirements September 2004

    because they provide a stable, routable address.  Services bound
    to the addresses of physical interface addresses might become
    unreachable if the associated hardware goes down, is removed, etc.
    This requirement makes it possible to restrict access to
    management services using routing.  Management services may be
    bound only to the addresses of loopback interfaces.  The loopback
    interfaces may be addressed out of net-blocks that are only routed
    between the managed devices and the authorized management
    networks/hosts.  This has the effect of making it impossible for
    anyone to connect to (or attempt to DoS) management services from
    anywhere but the authorized management networks/hosts.
    It also greatly reduces the need for complex filters.  It reduces
    the number of ports listening, and thus the number of potential
    avenues of attack.  It ensures that only traffic arriving from
    legitimate addresses and/or on designated interfaces can access
    services on the device.
 Examples.
    If the device listens for inbound SSH connections, this
    requirement means that it should be possible to specify that the
    device will only listen to connections destined to specific
    addresses (e.g., the address of the loopback interface) or
    received on certain interfaces (e.g., an Ethernet interface
    designated as the "management" interface).  It should be possible
    in this example to configure the device such that the SSH is NOT
    listening to every address configured on the device.  Similar
    effects may be achieved with the use of global filters, sometimes
    called "receive" or "loopback" ACLs, that filter traffic destined
    for the device itself on all interfaces.
 Warnings.
    None.

2.5.4. Ability to Control Service Source Addresses

 Requirement.
    The device MUST provide a means that allows the user to specify
    the source addresses used for all outbound connections or
    transmissions originating from the device.  It SHOULD be possible
    to specify source addresses independently for each type of
    outbound connection or transmission.  Source addresses MUST be
    limited to addresses that are assigned to interfaces (including
    loopbacks) local to the device.

Jones Informational [Page 31] RFC 3871 Operational Security Requirements September 2004

 Justification.
    This allows remote devices receiving connections or transmissions
    to use source filtering as one means of authentication.  For
    example, if SNMP traps were configured to use a known loopback
    address as their source, the SNMP workstation receiving the traps
    (or a firewall in front of it) could be configured to receive SNMP
    packets only from that address.
 Examples.
    The operator may allocate a distinct block of addresses from which
    all loopbacks are numbered.   NTP and syslog can be configured to
    use those loopback addresses as source, while SNMP and BGP may be
    configured to use specific physical interface addresses.  This
    would facilitate filtering based on source address as one way of
    rejecting unauthorized attempts to connect to peers/servers.
 Warnings.
    Care should be taken to assure that the addresses chosen are
    routable between the sending and receiving devices, (e.g., setting
    SSH to use a loopback address of 10.1.1.1 which is not routed
    between a router and all intended destinations could cause
    problems).
    Note that some protocols, such as SCTP [RFC3309], can use more
    than one IP address as the endpoint of a single connection.
    Also note that [RFC3631] lists address-based authentication as an
    "insecurity mechanism".  Address based authentication should be
    replaced or augmented by other mechanisms wherever possible.

2.5.5. Support Automatic Anti-spoofing for Single-Homed Networks

 Requirement.
    The device MUST provide a means to designate particular interfaces
    as servicing "single-homed networks" (see Section 1.8) and MUST
    provide an option to automatically drop "spoofed packets" (Section
    1.8) received on such interfaces where application of the current
    forwarding table would not route return traffic back through the
    same interface.  This option MUST work in the presence of dynamic
    routing and dynamically assigned addresses.

Jones Informational [Page 32] RFC 3871 Operational Security Requirements September 2004

 Justification.
    See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of
    [RFC1812], and [RFC2827].
 Examples.
    This requirement could be satisfied in several ways.  It could be
    satisfied by the provision of a single command that automatically
    generates and applies filters to an interface that implements
    anti-spoofing.  It could be satisfied by the provision of a
    command that causes the return path for packets received to be
    checked against the current forwarding tables and dropped if they
    would not be forwarded back through the interface on which they
    were received.
    See [RFC3704].
 Warnings.
    This requirement only holds for single-homed networks.  Note that
    a simple forwarding table check is not sufficient in the more
    complex scenarios of multi-homed or multi-attached networks, i.e.,
    where the traffic may be asymmetric.  In these cases, a more
    extensive check such as Feasible Path RPF could be very useful.

2.5.6. Support Automatic Discarding Of Bogons and Martians

 Requirement.
    The device MUST provide a means to automatically drop all "bogons"
    (Section 1.8) and "martians" (Section 1.8).  This option MUST work
    in the presence of dynamic routing and dynamically assigned
    addresses.
 Justification.
    These sorts of packets have little (no?) legitimate use and are
    used primarily to allow individuals and organization to avoid
    identification (and thus accountability) and appear to be most
    often used for DoS attacks, email abuse, hacking, etc.  In
    addition, transiting these packets needlessly consumes resources
    and may lead to capacity and performance problems for customers.
    See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of
    [RFC1812], and [RFC2827].

Jones Informational [Page 33] RFC 3871 Operational Security Requirements September 2004

 Examples.
    This requirement could be satisfied by the provision of a command
    that causes the return path for packets received to be checked
    against the current forwarding tables and dropped if no viable
    return path exists.  This assumes that steps are taken to assure
    that no bogon entries are present in the forwarding tables (for
    example filtering routing updates per Section 2.7.5 to reject
    advertisements of unassigned addresses).
    See [RFC3704].
 Warnings.
    This requirement only holds for single-homed networks.  Note that
    a simple forwarding table check is not sufficient in the more
    complex scenarios of multi-homed or multi-attached networks, i.e.,
    where the traffic may be asymmetric.  In these cases, a more
    extensive check such as Feasible Path RPF could be very useful.

2.5.7. Support Counters For Dropped Packets

 Requirement.
    The device MUST provide accurate, per-interface counts of spoofed
    packets dropped in accordance with Section 2.5.5 and Section
    2.5.6.
 Justification.
    Counters can help in identifying the source of spoofed traffic.
 Examples.
    An edge router may have several single-homed customers attached.
    When an attack using spoofed packets is detected, a quick check of
    counters may be able to identify which customer is attempting to
    send spoofed traffic.
 Warnings.
    None.

Jones Informational [Page 34] RFC 3871 Operational Security Requirements September 2004

2.6. Rate Limiting Requirements

2.6.1. Support Rate Limiting

 Requirement.
    The device MUST provide the capability to limit the rate at which
    it will pass traffic based on protocol, source and destination IP
    address or CIDR block, source and destination port, and interface.
    Protocols MUST include at least IP, ICMP, UDP, and TCP and SHOULD
    include any protocol.
 Justification.
    This requirement provides a means of reducing or eliminating the
    impact of certain types of attacks.  Also, rate limiting has the
    advantage that in some cases it can be turned on a priori, thereby
    offering some ability to mitigate the effect of future attacks
    prior to any explicit operator reaction to the attacks.
 Examples.
    Assume that a web hosting company provides space in its data-
    center to a company that becomes unpopular with a certain element
    of network users, who then decide to flood the web server with
    inbound ICMP traffic.  It would be useful in such a situation to
    be able to rate-filter inbound ICMP traffic at the data-center's
    border routers.  On the other side, assume that a new worm is
    released that infects vulnerable database servers such that they
    then start spewing traffic on TCP port 1433 aimed at random
    destination addresses as fast as the system and network interface
    of the infected  server is capable.  Further assume that a data
    center has many vulnerable servers that are infected and
    simultaneously sending large amounts of traffic with the result
    that all outbound links are saturated.  Implementation of this
    requirement, would allow the network operator to rate limit
    inbound and/or outbound TCP 1433 traffic (possibly to a rate of 0
    packets/bytes per second) to respond to the attack and maintain
    service levels for other legitimate customers/traffic.
 Warnings.
    None.

Jones Informational [Page 35] RFC 3871 Operational Security Requirements September 2004

2.6.2. Support Directional Application Of Rate Limiting Per Interface

 Requirement.
    The device MUST provide support to rate-limit input and/or output
    separately on each interface.
 Justification.
    This level of granular control allows appropriately targeted
    controls that minimize the impact on third parties.
 Examples.
    If an ICMP flood is directed a single customer on an edge router,
    it may be appropriate to rate-limit outbound ICMP only on that
    customers interface.
 Warnings.
    None.

2.6.3. Support Rate Limiting Based on State

 Requirement.
    The device MUST be able to rate limit based on all TCP control
    flag bits.  The device SHOULD support rate limiting of other
    stateful protocols where the normal processing of the protocol
    gives the device access to protocol state.
 Justification.
    This allows appropriate response to certain classes of attack.
 Examples.
    For example, for TCP sessions, it should be possible to rate limit
    based on the SYN, SYN-ACK, RST, or other bit state.
 Warnings.
    None.

Jones Informational [Page 36] RFC 3871 Operational Security Requirements September 2004

2.7. Basic Filtering Capabilities

2.7.1. Ability to Filter Traffic

 Requirement.
    The device MUST provide a means to filter IP packets on any
    interface implementing IP.
 Justification.
    Packet filtering is important because it provides a basic means of
    implementing policies that specify which traffic is allowed and
    which is not.  It also provides a basic tool for responding to
    malicious traffic.
 Examples.
    Access control lists that allow filtering based on protocol and/or
    source/destination address and or source/destination port would be
    one example.
 Warnings.
    None.

2.7.2. Ability to Filter Traffic TO the Device

 Requirement.
    It MUST be possible to apply the filtering mechanism to traffic
    that is addressed directly to the device via any of its interfaces
    - including loopback interfaces.
 Justification.
    This allows the operator to apply filters  that protect the device
    itself from attacks and unauthorized access.
 Examples.
    Examples of this might include filters that permit only BGP from
    peers and SNMP and SSH from an authorized management segment and
    directed to the device itself, while dropping all other traffic
    addressed to the device.

Jones Informational [Page 37] RFC 3871 Operational Security Requirements September 2004

 Warnings.
    None.

2.7.3. Ability to Filter Traffic THROUGH the Device

 Requirement.
    It MUST be possible to apply the filtering mechanism to traffic
    that is being routed (switched) through the device.
 Justification.
    This permits implementation of basic policies on devices that
    carry transit traffic (routers, switches, etc.).
 Examples.
    One simple and common way to meet this requirement is to provide
    the ability to filter traffic inbound to each interface and/or
    outbound from each interface.  Ingress filtering as described in
    [RFC2827] provides one example of the use of this capability.
 Warnings.
    None.

2.7.4. Ability to Filter Without Significant Performance Degradation

 Requirement.
    The device MUST provide a means to filter packets without
    significant performance degradation.  This specifically applies to
    stateless packet filtering operating on layer 3 (IP) and layer 4
    (TCP or UDP) headers, as well as normal packet forwarding
    information such as incoming and outgoing interfaces.
    The device MUST be able to apply stateless packet filters on ALL
    interfaces (up to the maximum number possible) simultaneously and
    with multiple filters per interface (e.g., inbound and outbound).
 Justification.
    This enables the implementation of filtering wherever and whenever
    needed.  To the extent that filtering causes degradation, it may
    not be possible to apply filters that implement the appropriate
    policies.

Jones Informational [Page 38] RFC 3871 Operational Security Requirements September 2004

 Examples.
    Another way of stating the requirement is that filter performance
    should not be the limiting factor in device throughput.  If a
    device is capable of forwarding 30Mb/sec without filtering, then
    it should be able to forward the same amount with filtering in
    place.
 Warnings.
    The definition of "significant" is subjective.  At one end of the
    spectrum it might mean "the application of filters may cause the
    box to crash".  At the other end would be a throughput loss of
    less than one percent with tens of thousands of filters applied.
    The level of performance degradation that is acceptable will have
    to be determined by the operator.
    Repeatable test data showing filter performance impact would be
    very useful in evaluating conformance with this requirement.
    Tests should include such information as packet size, packet rate,
    number of interfaces tested (source/destination), types of
    interfaces, routing table size, routing protocols in use,
    frequency of routing updates, etc.  See [bmwg-acc-bench].
    This requirement does not address stateful filtering, filtering
    above layer 4 headers or other more advanced types of filtering
    that may be important in certain operational environments.

2.7.5. Support Route Filtering

 Requirement.
    The device MUST provide a means to filter routing updates for all
    protocols used to exchange external routing information.
 Justification.
    See [RFC3013] and section 3.2 of [RFC2196].
 Examples.
    Operators may wish to ignore advertisements for routes to
    addresses allocated for private internets.  See eBGP.
 Warnings.
    None.

Jones Informational [Page 39] RFC 3871 Operational Security Requirements September 2004

2.7.6. Ability to Specify Filter Actions

 Requirement.
    The device MUST provide a mechanism to allow the specification of
    the action to be taken when a filter rule matches.  Actions MUST
    include "permit" (allow the traffic), "reject" (drop with
    appropriate notification to sender), and "drop" (drop with no
    notification to sender).  Also see Section 2.7.7 and Section 2.9
 Justification.
    This capability is essential to the use of filters to enforce
    policy.
 Examples.
    Assume that you have a small DMZ network connected to the
    Internet.  You want to allow management using SSH coming from your
    corporate office.  In this case, you might "permit" all traffic to
    port 22 in the DMZ from your corporate network, "rejecting" all
    others.  Port 22 traffic from the corporate network is allowed
    through.  Port 22 traffic from all other addresses results in an
    ICMP message to the sender.  For those who are slightly more
    paranoid, you might choose to "drop" instead of "reject" traffic
    from unauthorized addresses, with the result being that *nothing*
    is sent back to the source.
 Warnings.
    While silently dropping traffic without sending notification may
    be the correct action in security terms, consideration should be
    given to operational implications.  See [RFC3360] for
    consideration of potential problems caused by sending
    inappropriate TCP Resets.

2.7.7. Ability to Log Filter Actions

 Requirement.
    It MUST be possible to log all filter actions.  The logging
    capability MUST be able to capture at least the following data:
  • permit/deny/drop status,
  • source and destination IP address,
  • source and destination ports (if applicable to the protocol),

Jones Informational [Page 40] RFC 3871 Operational Security Requirements September 2004

  • which network element received the packet (interface, MAC

address or other layer 2 information that identifies the

       previous hop source of the packet).
       Logging of filter actions is subject to the requirements of
       Section 2.11.
 Justification.
    Logging is essential for auditing, incident response, and
    operations.
 Examples.
    A desktop network may not provide any services that should be
    accessible from "outside."  In such cases, all inbound connection
    attempts should be logged as possible intrusion attempts.
 Warnings.
    None.

2.8. Packet Filtering Criteria

2.8.1. Ability to Filter on Protocols

 Requirement.
    The device MUST provide a means to filter traffic based on the
    value of the protocol field in the IP header.
 Justification.
    Being able to filter on protocol is necessary to allow
    implementation of policy, secure operations and for support of
    incident response.
 Examples.
    Some denial of service attacks are based on the ability to flood
    the victim with ICMP traffic.  One quick way (admittedly with some
    negative side effects) to mitigate the effects of such attacks is
    to drop all ICMP traffic headed toward the victim.
 Warnings.
    None.

Jones Informational [Page 41] RFC 3871 Operational Security Requirements September 2004

2.8.2. Ability to Filter on Addresses

 Requirement.
    The function MUST be able to control the flow of traffic based on
    source and/or destination IP address or blocks of addresses such
    as Classless Inter-Domain Routing (CIDR) blocks.
 Justification.
    The capability to filter on addresses and address blocks is a
    fundamental tool for establishing boundaries between different
    networks.
 Examples.
    One example of the use of address based filtering is to implement
    ingress filtering per [RFC2827].
 Warnings.
    None.

2.8.3. Ability to Filter on Protocol Header Fields

 Requirement.
    The filtering mechanism MUST support filtering based on the
    value(s) of any portion of the protocol headers for IP, ICMP, UDP
    and TCP.  It SHOULD support filtering of all other protocols
    supported at layer 3 and 4.  It MAY support filtering based on the
    headers of higher level protocols.  It SHOULD be possible to
    specify fields by name (e.g., "protocol = ICMP") rather than bit-
    offset/length/numeric value (e.g., 72:8 = 1).
 Justification.
    Being able to filter on portions of the header is necessary to
    allow implementation of policy, secure operations, and support
    incident response.
 Examples.
    This requirement implies that it is possible to filter based on
    TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits,
    and ICMP type and code fields.  One common example is to reject
    "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear
    or SYN bit set+ACK,FIN and RST bits clear).  Another common

Jones Informational [Page 42] RFC 3871 Operational Security Requirements September 2004

    example is the ability to control what services are allowed in/out
    of a network.  It may be desirable to only allow inbound
    connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting
    web servers.
 Warnings.
    None.

2.8.4. Ability to Filter Inbound and Outbound

 Requirement.
    It MUST be possible to filter both incoming and outgoing traffic
    on any interface.
 Justification.
    This requirement allows flexibility in applying filters at the
    place that makes the most sense.  It allows invalid or malicious
    traffic to be dropped as close to the source as possible.
 Examples.
    It might be desirable on a border router, for example, to apply an
    egress filter outbound on the interface that connects a site to
    its external ISP to drop outbound traffic that does not have a
    valid internal source address.  Inbound, it might be desirable to
    apply a filter that blocks all traffic from a site that is known
    to forward or originate lots of junk mail.
 Warnings.
    None.

2.9. Packet Filtering Counter Requirements

2.9.1. Ability to Accurately Count Filter Hits

 Requirement.
    The device MUST supply a facility for accurately counting all
    filter hits.

Jones Informational [Page 43] RFC 3871 Operational Security Requirements September 2004

 Justification.
    Accurate counting of filter rule matches is important because it
    shows the frequency of attempts to violate policy.  This enables
    resources to be focused on areas of greatest need.
 Examples.
    Assume, for example, that a ISP network implements anti-spoofing
    egress filters (see [RFC2827]) on interfaces of its edge routers
    that support single-homed stub networks.  Counters could enable
    the ISP to detect cases where large numbers of spoofed packets are
    being sent.  This may indicate that the customer is performing
    potentially malicious actions (possibly in violation of the ISPs
    Acceptable Use Policy), or that system(s) on the customers network
    have been "owned" by hackers and are being (mis)used to launch
    attacks.
 Warnings.
    None.

2.9.2. Ability to Display Filter Counters

 Requirement.
    The device MUST provide a mechanism to display filter counters.
 Justification.
    Information that is collected is not useful unless it can be
    displayed in a useful manner.
 Examples.
    Assume there is a router with four interfaces.  One is an up-link
    to an ISP providing routes to the Internet.  The other three
    connect to separate internal networks.  Assume that a host on one
    of the internal networks has been compromised by a hacker and is
    sending traffic with bogus source addresses.  In such a situation,
    it might be desirable to apply ingress filters to each of the
    internal interfaces.  Once the filters are in place, the counters
    can be examined to determine the source (inbound interface) of the
    bogus packets.
 Warnings.
    None.

Jones Informational [Page 44] RFC 3871 Operational Security Requirements September 2004

2.9.3. Ability to Display Filter Counters per Rule

 Requirement.
    The device MUST provide a mechanism to display filter counters per
    rule.
 Justification.
    This makes it possible to see which rules are matching and how
    frequently.
 Examples.
    Assume that a filter has been defined that has two rules, one
    permitting all SSH traffic (tcp/22) and the second dropping all
    remaining traffic.  If three packets are directed toward/through
    the point at which the filter is applied, one to port 22, the
    others to different ports, then the counter display should show 1
    packet matching the permit tcp/22 rule and 2 packets matching the
    deny all others rule.
 Warnings.
    None.

2.9.4. Ability to Display Filter Counters per Filter Application

 Requirement.
    If it is possible for a filter to be applied more than once at the
    same time, then the device MUST provide a mechanism to display
    filter counters per filter application.
 Justification.
    It may make sense to apply the same filter definition
    simultaneously more than one time (to different interfaces, etc.).
    If so, it would be much more useful to know which instance of a
    filter is matching than to know that some instance was matching
    somewhere.
 Examples.
    One way to implement this requirement would be to have the counter
    display mechanism show the interface (or other entity) to which
    the filter has been applied, along with the name (or other
    designator) for the filter.  For example if a filter named

Jones Informational [Page 45] RFC 3871 Operational Security Requirements September 2004

    "desktop_outbound" applied two different interfaces, say,
    "ethernet0" and "ethernet1", the display should indicate something
    like "matches of filter 'desktop_outbound' on ethernet0 ..." and
    "matches of filter 'desktop_outbound' on ethernet1 ..."
 Warnings.
    None.

2.9.5. Ability to Reset Filter Counters

 Requirement.
    It MUST be possible to reset counters to zero on a per filter
    basis.
    For the purposes of this requirement it would be acceptable for
    the system to maintain two counters: an "absolute counter",
    C[now], and a "reset" counter, C[reset].  The absolute counter
    would maintain counts that increase monotonically until they wrap
    or overflow the counter.  The reset counter would receive a copy
    of the current value of the absolute counter when the reset
    function was issued for that counter.  Functions that display or
    retrieve the counter could then display the delta (C[now] -
    C[reset]).
 Justification.
    This allows operators to get a current picture of the traffic
    matching particular rules/filters.
 Examples.
    Assume that filter counters are being used to detect internal
    hosts that are infected with a new worm.  Once it is believed that
    all infected hosts have been cleaned up and the worm removed, the
    next step would be to verify that.  One way of doing so would be
    to reset the filter counters to zero and see if traffic indicative
    of the worm has ceased.
 Warnings.
    None.

Jones Informational [Page 46] RFC 3871 Operational Security Requirements September 2004

2.9.6. Filter Counters Must Be Accurate

 Requirement.
    Filter counters MUST be accurate.  They MUST reflect the actual
    number of matching packets since the last counter reset.  Filter
    counters MUST be capable of holding up to 2^32 - 1 values without
    overflowing and SHOULD be capable of holding up to 2^64 - 1
    values.
 Justification.
    Inaccurate data can not be relied on as the basis for action.
    Underreported data can conceal the magnitude of a problem.
 Examples.
    If N packets matching a filter are sent to/through a device, then
    the counter should show N matches.
 Warnings.
    None.

2.10. Other Packet Filtering Requirements

2.10.1. Ability to Specify Filter Log Granularity

 Requirement.
    It MUST be possible to enable/disable logging on a per rule basis.
 Justification.
    The ability to tune the granularity of logging allows the operator
    to log only the information that is desired.  Without this
    capability, it is possible that extra data (or none at all) would
    be logged, making it more difficult to find relevant information.
 Examples.
    If a filter is defined that has several rules, and one of the
    rules denies telnet (tcp/23) connections, then it should be
    possible to specify that only matches on the rule that denies
    telnet should generate a log message.

Jones Informational [Page 47] RFC 3871 Operational Security Requirements September 2004

 Warnings.
    None.

2.11. Event Logging Requirements

2.11.1. Logging Facility Uses Protocols Subject To Open Review

 Requirement.
    The device MUST provide a logging facility that is based on
    protocols subject to open review.  See Section 1.8.  Custom or
    proprietary logging protocols MAY be implemented provided the same
    information is made available.
 Justification.
    The use of logging based on protocols subject to open review
    permits the operator to perform archival and analysis of logs
    without relying on vendor-supplied software and servers.
 Examples.
    This requirement may be satisfied by the use of one or more of
    syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+
    [RFC1492] or RADIUS [RFC2865].
 Warnings.
    While [RFC3164] meets this requirement, it has many security
    issues and by itself does not meet the requirements of Section
    2.1.1.  See the security considerations section  of [RFC3164] for
    a list of issues.  [RFC3195] provides solutions to most/all of
    these issues....however at the time of this writing there are few
    implementations.  Other possible solutions might be to tunnel
    syslog over a secure transport...but this often raises difficult
    key management and scalability issues.
    The current best solution seems to be the following:
  • Implement [RFC3164].
  • Consider implementing [RFC3195].

Jones Informational [Page 48] RFC 3871 Operational Security Requirements September 2004

2.11.2. Logs Sent To Remote Servers

 Requirement.
    The device MUST support transmission of records of security
    related events to one or more remote devices.  There MUST be
    configuration settings on the device that allow selection of
    servers.
 Justification.
    This is important because it supports individual accountability.
    It is important to store them on a separate server to preserve
    them in case of failure or compromise of the managed device.
 Examples.
    This requirement may be satisfied by the use of one or more of:
    syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+
    [RFC1492] or RADIUS [RFC2865].
 Warnings.
    Note that there may be privacy or legal considerations when
    logging/monitoring user activity.
    High volumes of logging may generate excessive network traffic
    and/or compete for scarce memory and CPU resources on the device.

2.11.3. Ability to Select Reliable Delivery

 Requirement.
    It SHOULD be possible to select reliable delivery of log messages.
 Justification.
    Reliable delivery is important to the extent that log data is
    depended upon to make operational decisions and forensic analysis.
    Without reliable delivery, log data becomes a collection of hints.
 Examples.
    One example of reliable syslog delivery is defined in [RFC3195].
    Syslog-ng provides another example, although the protocol has not
    been standardized.

Jones Informational [Page 49] RFC 3871 Operational Security Requirements September 2004

 Warnings.
    None.

2.11.4. Ability to Log Locally

 Requirement.
    It SHOULD be possible to log locally on the device itself.  Local
    logging SHOULD be written to non-volatile storage.
 Justification.
    Local logging of failed authentication attempts to non-volatile
    storage is critical.  It provides a means of detecting attacks
    where the device is isolated from its authentication interfaces
    and attacked at the console.
    Local logging is important for viewing information when connected
    to the device.  It provides some backup of log data in case remote
    logging fails.  It provides a way to view logs relevant to one
    device without having to sort through a possibly large set of logs
    from other devices.
 Examples.
    One example of local logging would be a memory buffer that
    receives copies of messages sent to the remote log server.
    Another example might be a local syslog server (assuming the
    device is capable of running syslog and has some local storage).
 Warnings.
    Storage on the device may be limited.  High volumes of logging may
    quickly fill available storage, in which case there are two
    options: new logs overwrite old logs (possibly via the use of a
    circular memory buffer or log file rotation), or logging stops.

2.11.5. Ability to Maintain Accurate System Time

 Requirement.
    The device MUST maintain accurate, "high resolution" (see
    definition in Section 1.8) system time.

Jones Informational [Page 50] RFC 3871 Operational Security Requirements September 2004

 Justification.
    Accurate time is important to the generation of reliable log data.
    Accurate time is also important to the correct operation of some
    authentication mechanisms.
 Examples.
    This requirement may be satisfied by supporting Network Time
    Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct
    connection to an accurate time source.
 Warnings.
    System clock chips are inaccurate to varying degrees.  System time
    should not be relied upon unless it is regularly checked and
    synchronized with a known, accurate external time source (such as
    an NTP stratum-1 server).  Also note that if network time
    synchronization is used, an attacker may be able to manipulate the
    clock unless cryptographic authentication is used.

2.11.6. Display Timezone And UTC Offset

 Requirement.
    All displays and logs of system time MUST include a timezone or
    offset from UTC.
 Justification.
    Knowing the timezone or UTC offset makes correlation of data and
    coordination with data in other timezones possible.
 Examples.
    Bob is in Newfoundland, Canada which is UTC -3:30.  Alice is
    somewhere in Indiana, USA.  Some parts of Indiana switch to
    daylight savings time while others do not.  A user on Bob's
    network attacks a user on Alice's network.  Both are using logs
    with local timezones and no indication of UTC offset.  Correlating
    these logs will be difficult and error prone.  Including timezone,
    or better, UTC offset, eliminates these difficulties.
 Warnings.
    None.

Jones Informational [Page 51] RFC 3871 Operational Security Requirements September 2004

2.11.7. Default Timezone Should Be UTC

 Requirement.
    The default timezone for display and logging SHOULD be UTC.  The
    device MAY support a mechanism to allow the operator to specify
    the display and logging of times in a timezone other than UTC.
 Justification.
    Knowing the timezone or UTC offset makes correlation of data and
    coordination with data in other timezones possible.
 Examples.
    Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or
    UTC -6 depending on the time of year and exact county in Indiana)
    are working an incident together using their logs.  Both left the
    default settings, which was UTC, so there was no translation of
    time necessary to correlate the logs.
 Warnings.
    None.

2.11.8. Logs Must Be Timestamped

 Requirement.
    By default, the device MUST timestamp all log messages.  The
    timestamp MUST be accurate to within a second or less.  The
    timestamp MUST include a timezone.  There MAY be a mechanism to
    disable the generation of timestamps.
 Justification.
    Accurate timestamps are necessary for correlating events,
    particularly across multiple devices or with other organizations.
    This applies when it is necessary to analyze logs.
 Examples.
    This requirement MAY be satisfied by writing timestamps into
    syslog messages.

Jones Informational [Page 52] RFC 3871 Operational Security Requirements September 2004

 Warnings.
    It is difficult to correlate logs from different time zones.
    Security events on the Internet often involve machines and logs
    from a variety of physical locations.  For that reason, UTC is
    preferred, all other things being equal.

2.11.9. Logs Contain Untranslated IP Addresses

 Requirement.
    Log messages MUST NOT list translated addresses (DNS names)
    associated with the address without listing the untranslated IP
    address where the IP address is available to the device generating
    the log message.
 Justification.
    Including IP address of access list violations authentication
    attempts, address lease assignments and similar events in logs
    enables a level of individual and organizational accountability
    and is necessary to enable analysis of network events, incidents,
    policy violations, etc.
    DNS entries tend to change more quickly than IP block assignments.
    This makes the address more reliable for data forensics.
    DNS lookups can be slow and consume resources.
 Examples.
    A failed network login should generate a record with the source
    address of the login attempt.
 Warnings.
  • Source addresses may be spoofed. Network-based attacks often

use spoofed source addresses. Source addresses should not be

       completely trusted unless verified by other means.
  • Addresses may be reassigned to different individual, for

example, in a desktop environment using DHCP. In such cases

       the individual accountability afforded by this requirement is
       weak.  Having accurate time in the logs increases the chances
       that the use of an address can be correlated to an individual.

Jones Informational [Page 53] RFC 3871 Operational Security Requirements September 2004

  • Network topologies may change. Even in the absence of dynamic

address assignment, network topologies and address block

       assignments do change.  Logs of an attack one month ago may not
       give an accurate indication of which host, network or
       organization owned the system(s) in question at the time.

2.11.10. Logs Contain Records Of Security Events

 Requirement.
    The device MUST be able to send a record of at least the following
    events:
  • authentication successes,
  • authentication failures,
  • session Termination,
  • authorization changes,
  • configuration changes,
  • device status changes.
    The device SHOULD be able to send a record of all other security
    related events.
 Justification.
    This is important because it supports individual accountability.
    See section 4.5.4.4 of [RFC2196].
 Examples.
    Examples of events for which there must be a record include: user
    logins, bad login attempts, logouts, user privilege level changes,
    individual configuration commands issued by users and system
    startup/shutdown events.
 Warnings.
    This list is far from complete.
    Note that there may be privacy or legal considerations when
    logging/monitoring user activity.

Jones Informational [Page 54] RFC 3871 Operational Security Requirements September 2004

2.11.11. Logs Do Not Contain Passwords

 Requirement.
    Passwords SHOULD be excluded from all audit records, including
    records of successful or failed authentication attempts.
 Justification.
    Access control and authorization requirements differ for
    accounting records (logs) and authorization databases (passwords).
    Logging passwords may grant unauthorized access to individuals
    with access to the logs.  Logging failed passwords may give hints
    about actual passwords.  See section 4.5.4.4 of [RFC2196].
 Examples.
    A user may make small mistakes in entering a password such as
    using incorrect capitalization ("my password" vs. "My Password").
 Warnings.
    There may be situations where it is appropriate/required to log
    passwords.

2.12. Authentication, Authorization, and Accounting (AAA) Requirements

2.12.1. Authenticate All User Access

 Requirement.
    The device MUST provide a facility to perform authentication of
    all user access to the system.
 Justification.
    This functionality is required so that access to the system can be
    restricted to authorized personnel.
 Examples.
    This requirement MAY be satisfied by implementing a centralized
    authentication system.  See Section 2.12.5.  It MAY also be
    satisfied using local authentication.  See Section 2.12.6.
 Warnings.
    None.

Jones Informational [Page 55] RFC 3871 Operational Security Requirements September 2004

2.12.2. Support Authentication of Individual Users

 Requirement.
    Mechanisms used to authenticate interactive access for
    configuration and management MUST support the authentication of
    distinct, individual users.  This requirement MAY be relaxed to
    support system installation Section 2.4.5 or recovery of
    authorized access Section 2.12.15.
 Justification.
    The use of individual accounts, in conjunction with logging,
    promotes accountability.  The use of group or default accounts
    undermines individual accountability.
 Examples.
    A user may need to log in to the device to access CLI functions
    for management.  Individual user authentication could be provided
    by a centralized authentication server or a username/password
    database stored on the device.  It would be a violation of this
    rule for the device to only support a single "account" (with or
    without a username) and a single password shared by all users to
    gain administrative access.
 Warnings.
    This simply requires that the mechanism to support individual
    users be present.  Policy (e.g., forbidding shared group accounts)
    and enforcement are also needed but beyond the scope of this
    document.

2.12.3. Support Simultaneous Connections

 Requirement.
    The device MUST support multiple simultaneous connections by
    distinct users, possibly at different authorization levels.
 Justification.
    This allows multiple people to perform authorized management
    functions simultaneously.  This also means that attempted
    connections by unauthorized users do not automatically lock out
    authorized users.

Jones Informational [Page 56] RFC 3871 Operational Security Requirements September 2004

 Examples.
    None.
 Warnings.
    None.

2.12.4. Ability to Disable All Local Accounts

 Requirement.
    The device MUST provide a means of disabling all local accounts
    including:
  • local users,
  • default accounts (vendor, maintenance, guest, etc.),
  • privileged and unprivileged accounts.
    A local account defined as one where all information necessary for
    user authentication is stored on the device.
 Justification.
    Default accounts, well-known accounts, and old accounts provide
    easy targets for someone attempting to gain access to a device.
    It must be possible to disable them to reduce the potential
    vulnerability.
 Examples.
    The implementation depends on the types of authentication
    supported by the device.
 Warnings.
    None.

2.12.5. Support Centralized User Authentication Methods

 Requirement.
    The device MUST support a method of centralized authentication of
    all user access via standard authentication protocols.

Jones Informational [Page 57] RFC 3871 Operational Security Requirements September 2004

 Justification.
    Support for centralized authentication is particularly important
    in large environments where the network devices are widely
    distributed and where many people have access to them.  This
    reduces the effort needed to effectively restrict and track access
    to the system by authorized personnel.
 Examples.
    This requirement can be satisfied through the use of DIAMETER
    [RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos
    [RFC1510].
    The secure management requirements (Section 2.1.1) apply to AAA.
    See [RFC3579] for a discussion security issues related to RADIUS.
 Warnings.
    None.

2.12.6. Support Local User Authentication Method

 Requirement.
    The device SHOULD support a local authentication method.  If
    implemented, the method MUST NOT require interaction with anything
    external to the device (such as remote AAA servers),  and MUST
    work in conjunction with Section 2.3.1 (Support a 'Console'
    Interface) and Section 2.12.7 (Support Configuration of Order of
    Authentication Methods).
 Justification.
    Support for local authentication may be required in smaller
    environments where there may be only a few devices and a limited
    number of people with access.  The overhead of maintaining
    centralized authentication servers may not be justified.
 Examples.
    The use of local, per-device usernames and passwords provides one
    way to implement this requirement.

Jones Informational [Page 58] RFC 3871 Operational Security Requirements September 2004

 Warnings.
    Authentication information must be protected wherever it resides.
    Having, for instance, local usernames and passwords stored on 100
    network devices means that there are 100 potential points of
    failure where the information could be compromised vs. storing
    authentication data centralized server(s), which would reduce the
    potential points of failure to the number of servers and allow
    protection efforts (system hardening, audits, etc.) to be focused
    on, at most, a few servers.

2.12.7. Support Configuration of Order of Authentication Methods

 Requirement.
    The device MUST support the ability to configure the order in
    which supported authentication methods are attempted.
    Authentication SHOULD "fail closed", i.e., access should be denied
    if none of the listed authentication methods succeeds.
 Justification.
    This allows the operator flexibility in implementing appropriate
    security policies that balance operational and security needs.
 Examples.
    If, for example, a device supports RADIUS authentication and local
    usernames and passwords, it should be possible to specify that
    RADIUS authentication should be attempted if the servers are
    available, and that local usernames and passwords should be used
    for authentication only if the RADIUS servers are not available.
    Similarly, it should be possible to specify that only RADIUS or
    only local authentication be used.
 Warnings.
    None.

2.12.8. Ability To Authenticate Without Plaintext Passwords

 Requirement.
    The device MUST support mechanisms that do not require the
    transmission of plaintext passwords in all cases that require the
    transmission of authentication information across networks.

Jones Informational [Page 59] RFC 3871 Operational Security Requirements September 2004

 Justification.
    Plaintext passwords can be easily observed using packet sniffers
    on shared networks.  See [RFC1704] and [RFC3631] for a through
    discussion.
 Examples.
    Remote login requires the transmission of authentication
    information across networks.  Telnet transmits plaintext
    passwords.  SSH does not.  Telnet fails this requirement.  SSH
    passes.
 Warnings.
    None.

2.12.9. No Default Passwords

 Requirement.
    The initial configuration of the device MUST NOT contain any
    default passwords or other authentication tokens.
 Justification.
    Default passwords provide an easy way for attackers to gain
    unauthorized access to the device.
 Examples.
    Passwords such as the name of the vendor, device, "default", etc.
    are easily guessed.  The SNMP community strings "public" and
    "private" are well known defaults that provide read and write
    access to devices.
 Warnings.
    Lists of default passwords for various devices are readily
    available at numerous websites.

2.12.10. Passwords Must Be Explicitly Configured Prior To Use

 Requirement.
    The device MUST require the operator to explicitly configure
    "passwords" prior to use.

Jones Informational [Page 60] RFC 3871 Operational Security Requirements September 2004

 Justification.
    This requirement is intended to prevent unauthorized management
    access.  Requiring the operator to explicitly configure passwords
    will tend to have the effect of ensuring a diversity of passwords.
    It also shifts the responsibility for password selection to the
    user.
 Examples.
    Assume that a device comes with console port for management and a
    default administrative account.  This requirement together with No
    Default Passwords says that the administrative account should come
    with no password configured.  One way of meeting this requirement
    would be to have the device require the operator to choose a
    password for the administrative account as part of a dialog the
    first time the device is configured.
 Warnings.
    While this device requires operators to set passwords, it does not
    prevent them from doing things such as using scripts to configure
    hundreds of devices with the same easily guessed passwords.

2.12.11. Ability to Define Privilege Levels

 Requirement.
    It MUST be possible to define arbitrary subsets of all management
    and configuration functions and assign them to groups or
    "privilege levels", which can be assigned to users per Section
    2.12.12.  There MUST be at least three possible privilege levels.
 Justification.
    This requirement supports the implementation of the principal of
    "least privilege", which states that an individual should only
    have the privileges necessary to execute the operations he/she is
    required to perform.
 Examples.
    Examples of privilege levels might include "user" which only
    allows the initiation of a PPP or telnet session, "read only",
    which allows read-only access to device configuration and
    operational statistics, "root/superuser/administrator" which
    allows update access to all configurable parameters, and
    "operator" which allows updates to a limited, user defined set of

Jones Informational [Page 61] RFC 3871 Operational Security Requirements September 2004

    parameters.  Note that privilege levels may be defined locally on
    the device or on centralized authentication servers.
 Warnings.
    None.

2.12.12. Ability to Assign Privilege Levels to Users

 Requirement.
    The device MUST be able to assign a defined set of authorized
    functions, or "privilege level", to each user once they have
    authenticated themselves to the device.  Privilege level
    determines which functions a user is allowed to execute.  Also see
    Section 2.12.11.
 Justification.
    This requirement supports the implementation of the principal of
    "least privilege", which states that an individual should only
    have the privileges necessary to execute the operations he/she is
    required to perform.
 Examples.
    The implementation of this requirement will obviously be closely
    coupled with the authentication mechanism.  If RADIUS is used, an
    attribute could be set in the user's RADIUS profile that can be
    used to map the ID to a certain privilege level.
 Warnings.
    None.

2.12.13. Default Privilege Level Must Be 'None'

 Requirement.
    The default privilege level SHOULD NOT allow any access to
    management or configuration functions.  It MAY allow access to
    user-level functions (e.g., starting PPP or telnet).  It SHOULD be
    possible to assign a different privilege level as the default.
    This requirement MAY be relaxed to support system installation per
    Section 2.4.5 or recovery of authorized access per Section
    2.12.15.

Jones Informational [Page 62] RFC 3871 Operational Security Requirements September 2004

 Justification.
    This requirement supports the implementation of the principal of
    "least privilege", which states that an individual should only
    have the privileges necessary to execute the operations he/she is
    required to perform.
 Examples.
    Examples of privilege levels might include "user" which only
    allows the initiation of a PPP or telnet session, "read-only",
    which allows read-only access to device configuration and
    operational statistics, "root/superuser/administrator" which
    allows update access to all configurable parameters, and
    "operator" which allows updates to a limited, user defined set of
    parameters.  Note that privilege levels may be defined locally on
    the device or on centralized authentication servers.
 Warnings.
    It may be required to provide exceptions to support the
    requirements to support recovery of privileged access (Section
    2.12.15) and to support OS installation and configuration (Section
    2.4.5).  For example, if the OS and/or configuration has somehow
    become corrupt an authorized individual with physical access may
    need to have "root" level access to perform an install.

2.12.14. Change in Privilege Levels Requires Re-Authentication

 Requirement.
    The device MUST re-authenticate a user prior to granting any
    change in user authorizations.
 Justification.
    This requirement ensures that users are able to perform only
    authorized actions.
 Examples.
    This requirement might be implemented by assigning base privilege
    levels to all users and allowing the user to request additional
    privileges, with the requests validated by the AAA server.
 Warnings.
    None.

Jones Informational [Page 63] RFC 3871 Operational Security Requirements September 2004

2.12.15. Support Recovery Of Privileged Access

 Requirement.
    The device MUST support a mechanism to allow authorized
    individuals to recover full privileged administrative access in
    the event that access is lost.  Use of the mechanism MUST require
    physical access to the device.  There MAY be a mechanism for
    disabling the recovery feature.
 Justification.
    There are times when local administrative passwords are forgotten,
    when the only person who knows them leaves the company, or when
    hackers set or change the password.  In all these cases,
    legitimate administrative access to the device is lost.  There
    should be a way to recover access.  Requiring physical access to
    invoke the procedure makes it less likely that it will be abused.
    Some organizations may want an even higher level of security and
    be willing to risk total loss of authorized access by disabling
    the recovery feature, even for those with physical access.
 Examples.
    Some examples of ways to satisfy this requirement are to have the
    device give the user the chance to set a new administrative
    password when:
  • The user sets a jumper on the system board to a particular

position.

  • The user sends a special sequence to the RS232 console port

during the initial boot sequence.

  • The user sets a "boot register" to a particular value.
 Warnings.
    This mechanism, by design,  provides a "back door" to complete
    administrative control of the device and may not be appropriate
    for environments where those with physical access to the device
    can not be trusted.
    Also see the warnings in Section 2.3.1 (Support a 'Console'
    Interface).

Jones Informational [Page 64] RFC 3871 Operational Security Requirements September 2004

2.13. Layer 2 Devices Must Meet Higher Layer Requirements

 Requirement.
    If a device provides layer 2 services that are dependent on layer
    3 or greater services, then the portions that operate at or above
    layer 3 MUST conform to the requirements listed in this document.
 Justification.
    All layer 3 devices have similar security needs and should be
    subject to similar requirements.
 Examples.
    Signaling protocols required for layer 2 switching may exchange
    information with other devices using layer 3 communications.  In
    such cases, the device must provide a secure layer 3 facility.
    Also, if higher layer capabilities (say, SSH or SNMP) are used to
    manage a layer 2 device, then the rest of the requirements in this
    document apply to those capabilities.
 Warnings.
    None.

2.14. Security Features Must Not Cause Operational Problems

 Requirement.
    The use of security features specified by the requirements in this
    document SHOULD NOT cause severe operational problems.
 Justification.
    Security features which cause operational problems are not useful
    and may leave the operator with no mechanism for enforcing
    appropriate policy.
 Examples.
    Some examples of severe operational problems include:
  • The device crashes.
  • The device becomes unmanageable.
  • Data is lost.

Jones Informational [Page 65] RFC 3871 Operational Security Requirements September 2004

  • Use of the security feature consumes excessive resources (CPU,

memory, bandwidth).

 Warnings.
    Determination of compliance with this requirement involves a level
    of judgement.  What is "severe"?  Certainly crashing is severe,
    but what about a %5 loss in throughput when logging is enabled?
    It should also be noted that there may be unavoidable physical
    limitations such as the total capacity of a link.

2.15. Security Features Should Have Minimal Performance Impact

 Requirement.
    Security features specified by the requirements in this document
    SHOULD be implemented with minimal impact on performance.  Other
    sections of this document may specify different performance
    requirements (e.g., "MUST"s).
 Justification.
    Security features which significantly impact performance may leave
    the operator with no mechanism for enforcing appropriate policy.
 Examples.
    If the application of filters is known to have the potential to
    significantly reduce throughput for non-filtered traffic, there
    will be a tendency, or in some cases a policy, not to use filters.
    Assume, for example, that a new worm is released that scans random
    IP addresses looking for services listening on TCP port 1433.  An
    operator might want to investigate to see if any of the hosts on
    their networks were infected and trying to spread the worm.  One
    way to do this would be to put up non-blocking filters counting
    and logging the number of outbound connection 1433, and then to
    block the requests that are determined to be from infected hosts.
    If any of these capabilities (filtering, counting, logging) have
    the potential to impose severe performance penalties, then this
    otherwise rational course of action might not be possible.
 Warnings.
    Requirements for which performance is a particular concern
    include: filtering, rate-limiting, counters, logging and anti-
    spoofing.

Jones Informational [Page 66] RFC 3871 Operational Security Requirements September 2004

3. Documentation Requirements

 The requirements in this section are intended to list information
 that will assist operators in evaluating and securely operating a
 device.

3.1. Identify Services That May Be Listening

 Requirement.
    The vendor MUST provide a list of all services that may be active
    on the device.  The list MUST identify the protocols and default
    ports (if applicable) on which the services listen.  It SHOULD
    provide references to complete documentation describing the
    service.
 Justification.
    This information is necessary to enable a thorough assessment of
    the potential security risks associated with the operation of each
    service.
 Examples.
    The list will likely contain network and transport protocols such
    as IP, ICMP, TCP, UDP, routing protocols such as BGP and OSPF,
    application protocols such as SSH and SNMP along with references
    to the RFCs or other documentation describing the versions of the
    protocols implemented.
    Web servers "usually" listen on port 80.  In the default
    configuration of the device, it may have a web server listening on
    port 8080.  In the context of this requirement "identify ...
    default port" would mean "port 8080".
 Warnings.
    There may be valid, non-technical reasons for not disclosing the
    specifications of proprietary protocols.  In such cases, all that
    needs to be disclosed is the existence of the service and the
    default ports (if applicable).

3.2. Document Service Defaults

 Requirement.
    The vendor MUST provide a list of the default state of all
    services.

Jones Informational [Page 67] RFC 3871 Operational Security Requirements September 2004

 Justification.
    Understanding risk requires understanding exposure.  Each service
    that is enabled presents a certain level of exposure.  Having a
    list of the services that is enabled by default makes it possible
    to perform meaningful risk analysis.
 Examples.
    The list may be no more than the output of a command that
    implements Section 2.5.1.
 Warnings.
    None.

3.3. Document Service Activation Process

 Requirement.
    The vendor MUST concisely document which features enable and
    disable services.
 Justification.
    Once risk has been assessed, this list provides the operator a
    quick means of understanding how to disable (or enable) undesired
    (or desired) services.
 Examples.
    This may be a list of commands to enable/disable services one by
    one or a single command which enables/disables "standard" groups
    of commands.
 Warnings.
    None.

3.4. Document Command Line Interface

 Requirement.
    The vendor MUST provide complete documentation of the command line
    interface with each software release.  The documentation SHOULD
    include highlights of changes from previous versions.  The
    documentation SHOULD list potential output for each command.

Jones Informational [Page 68] RFC 3871 Operational Security Requirements September 2004

 Justification.
    Understanding of inputs and outputs is necessary to support
    scripting. See Section 2.4.2.
 Examples.
    Separate documentation should be provided for each command listing
    the syntax, parameters, options, etc. as well as expected output
    (status, tables, etc.).
 Warnings.
    None.

3.5. 'Console' Default Communication Profile Documented

 Requirement.
    The console default profile of communications parameters MUST be
    published in the system documentation.
 Justification.
    Publication in the system documentation makes the settings
    accessible.  Failure to publish them could leave the operator
    having to guess.
 Examples.
    None.
 Warnings.
    None.

4. Assurance Requirements

 The requirements in this section are intended to
 o  identify behaviors and information that will increase confidence
    that the device will meet the security functional requirements.
 o  Provide information that will assist in the performance of
    security evaluations.

Jones Informational [Page 69] RFC 3871 Operational Security Requirements September 2004

4.1. Identify Origin of IP Stack

 Requirement.
    The vendor SHOULD disclose the origin or basis of the IP stack
    used on the system.
 Justification.
    This information is required to better understand the possible
    security vulnerabilities that may be inherent in the IP stack.
 Examples.
    "The IP stack was derived from BSD 4.4", or "The IP stack was
    implemented from scratch."
 Warnings.
    Many IP stacks make simplifying assumptions about how an IP packet
    should be formed.  A malformed packet can cause unexpected
    behavior in the device, such as a system crash or buffer overflow
    which could result in  unauthorized access to the system.

4.2. Identify Origin of Operating System

 Requirement.
    The vendor SHOULD disclose the origin or basis of the operating
    system (OS).
 Justification.
    This information is required to better understand the security
    vulnerabilities that may be inherent to the OS based on its
    origin.
 Examples.
    "The operating system is based on Linux kernel 2.4.18."
 Warnings.
    None.

Jones Informational [Page 70] RFC 3871 Operational Security Requirements September 2004

5. Security Considerations

 General
    Security is the subject matter of this entire memo.  The
    justification section of each individual requirement lists the
    security implications of meeting or not meeting the requirement.
 SNMP
    SNMP versions prior to SNMPv3 did not include adequate security.
    Even if the network itself is secure (for example by using IPSec),
    even then, there is no control as to who on the secure network is
    allowed to access and GET/SET (read/change/create/delete) the
    objects in the MIB.
    It is recommended that implementors consider the security features
    as provided by the SNMPv3 framework (see [RFC3410], section 8),
    including full support for the SNMPv3 cryptographic mechanisms
    (for authentication and privacy).
    Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT
    RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
    enable cryptographic security.  It is then a customer/operator
    responsibility to ensure that the SNMP entity giving access to MIB
    objects is properly configured to give access to the objects only
    to those principals (users) that have legitimate rights to indeed
    GET or SET (change/create/delete) them.

6. References

6.1. Normative References

 [ANSI.X9-52.1998] American National Standards Institute, "Triple Data
                   Encryption Algorithm Modes of Operation", ANSI
                   X9.52, 1998.
 [FIPS.197]        National Institute of Standards and Technology,
                   "Advanced Encryption Standard", FIPS PUB 197,
                   November 2001,
                   <http://csrc.nist.gov/publications/fips/fips197/
                   fips-197.ps>.
 [PKCS.3.1993]     RSA Laboratories, "Diffie-Hellman Key-Agreement
                   Standard, Version 1.4", PKCS 3, November 1993.
 [RFC1208]         Jacobsen, O. and D. Lynch, "Glossary of networking
                   terms", RFC 1208, March 1991.

Jones Informational [Page 71] RFC 3871 Operational Security Requirements September 2004

 [RFC1321]         Rivest, R., "The MD5 Message-Digest Algorithm", RFC
                   1321, April 1992.
 [RFC1492]         Finseth, C., "An Access Control Protocol, Sometimes
                   Called TACACS", RFC 1492, July 1993.
 [RFC1510]         Kohl, J. and C. Neuman, "The Kerberos Network
                   Authentication Service (V5)", RFC 1510, September
                   1993.
 [RFC1704]         Haller, N. and R. Atkinson, "On Internet
                   Authentication", RFC 1704, October 1994.
 [RFC1812]         Baker, F., Ed., "Requirements for IP Version 4
                   Routers", RFC 1812, June 1995.
 [RFC1918]         Rekhter, Y., Moskowitz, B., Karrenberg, D., de
                   Groot, G., and E. Lear, "Address Allocation for
                   Private Internets", BCP 5, RFC 1918, February 1996.
 [RFC2026]         Bradner, S., "The Internet Standards Process --
                   Revision 3", BCP 9, RFC 2026, October 1996.
 [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2196]         Fraser, B., "Site Security Handbook", FYI 8, RFC
                   2196, September 1997.
 [RFC2246]         Dierks, T. and C. Allen, "The TLS Protocol Version
                   1.0", RFC 2246, January 1999.
 [RFC2385]         Heffernan, A., "Protection of BGP Sessions via the
                   TCP MD5 Signature Option", RFC 2385, August 1998.
 [RFC2401]         Kent, S. and R. Atkinson, "Security Architecture
                   for the Internet Protocol", RFC 2401, November
                   1998.
 [RFC2631]         Rescorla, E., "Diffie-Hellman Key Agreement
                   Method", RFC 2631, June 1999.
 [RFC2827]         Ferguson, P. and D. Senie, "Network Ingress
                   Filtering: Defeating Denial of Service Attacks
                   which employ IP Source Address Spoofing", BCP 38,
                   RFC 2827, May 2000.

Jones Informational [Page 72] RFC 3871 Operational Security Requirements September 2004

 [RFC2865]         Rigney, C., Willens, S., Rubens, A., and W.
                   Simpson, "Remote Authentication Dial In User
                   Service (RADIUS)", RFC 2865, June 2000.
 [RFC3013]         Killalea, T., "Recommended Internet Service
                   Provider Security Services and Procedures", BCP 46,
                   RFC 3013, November 2000.
 [RFC3164]         Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
                   August 2001.
 [RFC3174]         Eastlake, D. and P. Jones, "US Secure Hash
                   Algorithm 1 (SHA1)", RFC 3174, September 2001.
 [RFC3195]         New, D. and M. Rose, "Reliable Delivery for
                   syslog", RFC 3195, November 2001.
 [RFC3309]         Stone, J., Stewart, R. and D. Otis, "Stream Control
                   Transmission Protocol (SCTP) Checksum Change", RFC
                   3309, September 2002.
 [RFC3330]         IANA, "Special-Use IPv4 Addresses", RFC 3330,
                   September 2002.
 [RFC3360]         Floyd, S., "Inappropriate TCP Resets Considered
                   Harmful", BCP 60, RFC 3360, August 2002.
 [RFC3410]         Case, J., Mundy, R., Partain, D. and B. Stewart,
                   "Introduction and Applicability Statements for
                   Internet-Standard Management Framework", RFC 3410,
                   December 2002.
 [RFC3411]         Harrington, D., Presuhn, R., and B. Wijnen, "An
                   Architecture for Describing Simple Network
                   Management Protocol (SNMP) Management Frameworks",
                   STD 62, RFC 3411, December 2002.
 [RFC3447]         Jonsson, J. and B. Kaliski, "Public-Key
                   Cryptography Standards (PKCS) #1: RSA Cryptography
                   Specifications Version 2.1", RFC 3447, February
                   2003.
 [RFC3562]         Leech, M., "Key Management Considerations for the
                   TCP MD5 Signature Option", RFC 3562, July 2003.

Jones Informational [Page 73] RFC 3871 Operational Security Requirements September 2004

 [RFC3579]         Aboba, B. and P. Calhoun, "RADIUS (Remote
                   Authentication Dial In User Service) Support For
                   Extensible Authentication Protocol (EAP)", RFC
                   3579, September 2003.
 [RFC3588]         Calhoun, P., Loughney, J., Guttman, E., Zorn, G.,
                   and J. Arkko, "Diameter Base Protocol", RFC 3588,
                   September 2003.
 [RFC3631]         Bellovin, S., Schiller, J., and C. Kaufman, Eds.,
                   "Security Mechanisms for the Internet", RFC 3631,
                   December 2003.

6.2. Informative References

 [RFC3766]         Orman, H. and P. Hoffman, "Determining Strengths
                   For Public Keys Used For Exchanging Symmetric
                   Keys", BCP 86, RFC 3766, April 2004.
 [RFC3704]         Baker, F. and P. Savola, "Ingress Filtering for
                   Multihomed Networks", BCP 84, RFC 3704, March 2004.
 [bmwg-acc-bench]  Poretsky, S., "Framework for Accelerated Stress
                   Benchmarking", Work in Progress, October 2003.
 [Schneier]        Schneier, B., "Applied Cryptography, 2nd Ed.,
                   Publisher John Wiley & Sons, Inc.", 1996.

Jones Informational [Page 74] RFC 3871 Operational Security Requirements September 2004

Appendix A. Requirement Profiles

 This Appendix lists different profiles.  A profile is a list of list
 of requirements that apply to a particular class of devices.  The
 minimum requirements profile applies to all devices.

A.1. Minimum Requirements Profile

 The functionality listed here represents a minimum set of
 requirements to which managed infrastructure of large IP networks
 should adhere.
 The minimal requirements profile addresses functionality which will
 provide reasonable capabilities to manage the devices in the event of
 attacks, simplify troubleshooting, keep track of events which affect
 system integrity, help analyze causes of attacks, as well as provide
 administrators  control over IP addresses and protocols to help
 mitigate the most common attacks and exploits.
 o  Support Secure Channels For Management
 o  Use Protocols Subject To Open Review For Management
 o  Use Cryptographic Algorithms Subject To Open Review
 o  Use Strong Cryptography
 o  Allow Selection of Cryptographic Parameters
 o  Management Functions Should Have Increased Priority
 o  Support a 'Console' Interface
 o  'Console' Communication Profile Must Support Reset
 o  'Console' Default Communication Profile Documented
 o  'Console' Requires Minimal Functionality of Attached Devices.
 o  Support Separate Management Plane IP Interfaces
 o  No Forwarding Between Management Plane And Other Interfaces
 o  'CLI' Provides Access to All Configuration and Management
    Functions
 o  'CLI' Supports Scripting of Configuration

Jones Informational [Page 75] RFC 3871 Operational Security Requirements September 2004

 o  'CLI' Supports Management Over 'Slow' Links
 o  Document Command Line Interface
 o  Support Software Installation
 o  Support Remote Configuration Backup
 o  Support Remote Configuration Restore
 o  Support Text Configuration Files
 o  Ability to Identify All Listening Services
 o  Ability to Disable Any and All Services
 o  Ability to Control Service Bindings for Listening Services
 o  Ability to Control Service Source Addresses
 o  Ability to Filter Traffic
 o  Ability to Filter Traffic TO the Device
 o  Support Route Filtering
 o  Ability to Specify Filter Actions
 o  Ability to Log Filter Actions
 o  Ability to Filter Without Significant Performance Degradation
 o  Ability to Specify Filter Log Granularity
 o  Ability to Filter on Protocols
 o  Ability to Filter on Addresses
 o  Ability to Filter on Protocol Header Fields
 o  Ability to Filter Inbound and Outbound
 o  Packet Filtering Counter Requirements
 o  Ability to Display Filter Counters
 o  Ability to Display Filter Counters per Rule

Jones Informational [Page 76] RFC 3871 Operational Security Requirements September 2004

 o  Ability to Display Filter Counters per Filter Application
 o  Ability to Reset Filter Counters
 o  Filter Counters Must Be Accurate
 o  Logging Facility Uses Protocols Subject To Open Review
 o  Logs Sent To Remote Servers
 o  Ability to Log Locally
 o  Ability to Maintain Accurate System Time
 o  Display Timezone And UTC Offset
 o  Default Timezone Should Be UTC
 o  Logs Must Be Timestamped
 o  Logs Contain Untranslated IP Addresses
 o  Logs Contain Records Of Security Events
 o  Authenticate All User Access
 o  Support Authentication of Individual Users
 o  Support Simultaneous Connections
 o  Ability to Disable All Local Accounts
 o  Support Centralized User Authentication Methods
 o  Support Local User Authentication Method
 o  Support Configuration of Order of Authentication Methods
 o  Ability To Authenticate Without Plaintext Passwords
 o  Passwords Must Be Explicitly Configured Prior To Use
 o  No Default Passwords
 o  Ability to Define Privilege Levels
 o  Ability to Assign Privilege Levels to Users

Jones Informational [Page 77] RFC 3871 Operational Security Requirements September 2004

 o  Default Privilege Level Must Be 'None'
 o  Change in Privilege Levels Requires Re-Authentication
 o  Support Recovery Of Privileged Access
 o  Logs Do Not Contain Passwords
 o  Security Features Must Not Cause Operational Problems
 o  Security Features Should Have Minimal Performance Impact
 o  Identify Services That May Be Listening
 o  Document Service Defaults
 o  Document Service Activation Process
 o  Identify Origin of IP Stack
 o  Identify Origin of Operating System
 o  Identify Origin of IP Stack
 o  Identify Origin of Operating System
 o  Layer 2 Devices Must Meet Higher Layer Requirements

A.2. Layer 3 Network Edge Profile

 This section builds on the minimal requirements listed in A.1 and
 adds more stringent security functionality specific to layer 3
 devices which are part of the network edge.  The network edge is
 typically where much of the filtering and traffic control policies
 are implemented.
 An edge device is defined as a device that makes up the network
 infrastructure and connects directly to customers or peers.  This
 would include routers connected to peering points, switches
 connecting customer hosts, etc.
 o  Support Automatic Anti-spoofing for Single-Homed Networks
 o  Support Automatic Discarding Of Bogons and Martians
 o  Support Counters For Dropped Packets
 o  Support Rate Limiting

Jones Informational [Page 78] RFC 3871 Operational Security Requirements September 2004

 o  Support Directional Application Of Rate Limiting Per Interface
 o  Support Rate Limiting Based on State
 o  Ability to Filter Traffic THROUGH the Device

Appendix B. Acknowledgments

 This document grew out of an internal security requirements document
 used by UUNET for testing devices that were being proposed for
 connection to the backbone.
 The editor gratefully acknowledges the contributions of:
 o  Greg Sayadian, author of a predecessor of this document.
 o  Eric Brandwine, a major source of ideas/critiques.
 o  The MITRE Corporation for supporting continued development of this
    document.  NOTE: The editor's affiliation with The MITRE
    Corporation is provided for identification purposes only, and is
    not intended to convey or imply MITRE's concurrence with, or
    support for, the positions, opinions or viewpoints expressed by
    the editor.
 o  The former UUNET network security team: Jared Allison, Eric
    Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent King, Neil
    Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd MacDermid,
    Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow, Robert Stone,
    Anne Williams, Pete White.
 o  Others who have provided significant feedback at various stages of
    the life of this document are: Ran Atkinson, Fred Baker, Steve
    Bellovin, David L. Black, Michael H. Behringer, Matt Bishop, Scott
    Blake, Randy Bush, Pat Cain, Ross Callon, Steven Christey, Owen
    Delong, Sean Donelan, Robert Elmore, Barbara Fraser, Barry Greene,
    Jeffrey Haas, David Harrington, Dan Hollis, Jeffrey Hutzelman,
    Merike Kaeo, James Ko, John Kristoff, Chris Lonvick, Chris
    Liljenstolpe, James W. Laferriere, Jared Mauch, Perry E. Metzger,
    Mike O'Connor, Alan Paller, Rob Pickering, Pekka Savola, Gregg
    Schudel, Juergen Schoenwaelder, Don Smith, Rodney Thayer, David
    Walters, Joel N. Weber II, Russ White, Anthony Williams, Neal
    Ziring.
 o  Madge B. Harrison and Patricia L. Jones, technical writing review.
 o  This listing is intended to acknowledge contributions, not to
    imply that the individual or organizations approve the content of
    this document.

Jones Informational [Page 79] RFC 3871 Operational Security Requirements September 2004

 o  Apologies to those who commented on/contributed to the document
    and were not listed.

Author's Address

 George M. Jones, Editor
 The MITRE Corporation
 7515 Colshire Drive, M/S WEST
 McLean, Virginia  22102-7508
 U.S.A.
 Phone: +1 703 488 9740
 EMail: gmj3871@pobox.com

Jones Informational [Page 80] RFC 3871 Operational Security Requirements September 2004

Full Copyright Statement

 Copyright (C) The Internet Society (2004).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78, and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Jones Informational [Page 81]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3871.txt · Last modified: 2004/09/07 18:13 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki