tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3871

Informational
Pages: 81
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~internet

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

Part 1 of 3, p. 1 to 22
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part