Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3871

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

Pages: 81
Informational
Updated by:  8996
Part 1 of 3 – Pages 1 to 22
None   None   Next

Top   ToC   RFC3871 - Page 1
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.
Top   ToC   RFC3871 - Page 2

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
Top   ToC   RFC3871 - Page 3
             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
Top   ToC   RFC3871 - Page 4
             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
Top   ToC   RFC3871 - Page 5

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.
Top   ToC   RFC3871 - Page 6
   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)
Top   ToC   RFC3871 - Page 7
   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].
Top   ToC   RFC3871 - Page 8
      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.
Top   ToC   RFC3871 - Page 9
   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.
Top   ToC   RFC3871 - Page 10
   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
Top   ToC   RFC3871 - Page 11
         *  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.
Top   ToC   RFC3871 - Page 12
   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
Top   ToC   RFC3871 - Page 13
      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.
Top   ToC   RFC3871 - Page 14
      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.
Top   ToC   RFC3871 - Page 15
   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.
Top   ToC   RFC3871 - Page 16

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.
Top   ToC   RFC3871 - Page 17
   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.
Top   ToC   RFC3871 - Page 18
   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.
Top   ToC   RFC3871 - Page 19
   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.
Top   ToC   RFC3871 - Page 20
   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
Top   ToC   RFC3871 - Page 21
      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.
Top   ToC   RFC3871 - Page 22
   Justification.

      This prevents the flow, intentional or unintentional, of
      management traffic to/from places that it should not be
      originating/terminating (e.g., anything beyond the customer-facing
      interfaces).

   Examples.

      Implementing separate forwarding tables for management plane and
      non-management plane interfaces that do not propagate routes to
      each other satisfies this requirement.

   Warnings.

      None.



(page 22 continued on part 2)

Next Section