[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3871

None.                                                   G. Jones, Editor
Internet-Draft                                     The MITRE Corporation
Expires: June 15, 2004                                 December 16, 2003


    Operational Security Requirements for IP Network Infrastructure:
                         Best-Current-Practices
                          draft-jones-opsec-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 15, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document defines a list of operational security requirements for
   the infrastructure of large IP networks (routers and switches) which
   are considered to be best current practice (BCP). 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. Comments to: "opsec-comment@ops.ietf.org".







Jones, Editor            Expires June 15, 2004                  [Page 1]

Internet-Draft     Operational Security Requirements       December 2003


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 . . . . . . . . . . . . . .  5
   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  . . . . . . . . . . . . . 11
   2.2.1   Use Encryption Algorithms Subject To Open Review . . . . . 12
   2.2.2   Use Strong Encryption  . . . . . . . . . . . . . . . . . . 13
   2.2.3   Use Encryption in Protocols Subject To Open Review . . . . 14
   2.2.4   Allow Selection of Encryption Parameters . . . . . . . . . 14
   2.3     Out-of-Band (OoB) Management Requirements  . . . . . . . . 15
   2.3.1   Support a 'Console' interface  . . . . . . . . . . . . . . 15
   2.3.2   'Console' Has A Simple Default Communication Profile . . . 16
   2.3.3   'Console' Communication Profile Must Support Reset . . . . 16
   2.3.4   'Console' requires minimal functionality of attached
           devices. . . . . . . . . . . . . . . . . . . . . . . . . . 17
   2.3.5   'Console' Supports Fall-back Authentication  . . . . . . . 17
   2.3.6   Support Separate Management Plane IP Interfaces  . . . . . 18
   2.3.7   No Forwarding Between Management Plane And Other
           Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 18
   2.3.8   Provide Separate Resources For The Management Plane  . . . 19
   2.4     Configuration and Management Interface Requirements  . . . 19
   2.4.1   CLI Provides Access to All Configuration and
           Management Functions . . . . . . . . . . . . . . . . . . . 19
   2.4.2   CLI Supports Scripting of Configuration  . . . . . . . . . 20
   2.4.3   CLI Supports Management Over 'Slow' Links  . . . . . . . . 20
   2.4.4   CLI Supports Idle Session Timeout  . . . . . . . . . . . . 21
   2.4.5   Support Software Installation  . . . . . . . . . . . . . . 21
   2.4.6   Support Remote Configuration Backup  . . . . . . . . . . . 23
   2.4.7   Support Remote Configuration Restore . . . . . . . . . . . 23
   2.4.8   Support Text Configuration Files . . . . . . . . . . . . . 23
   2.5     IP Stack Requirements  . . . . . . . . . . . . . . . . . . 24
   2.5.1   Ability to Identify All Listening Services . . . . . . . . 24
   2.5.2   Ability to Disable Any and All Services  . . . . . . . . . 25
   2.5.3   Listening Services Should Be Off By Default  . . . . . . . 25
   2.5.4   Ability to Control Service Bindings for Listening
           Services . . . . . . . . . . . . . . . . . . . . . . . . . 25
   2.5.5   Ability to Control Service Source Address  . . . . . . . . 26
   2.5.6   Support Automatic Anti-spoofing for Single-Homed



Jones, Editor            Expires June 15, 2004                  [Page 2]

Internet-Draft     Operational Security Requirements       December 2003


           Networks . . . . . . . . . . . . . . . . . . . . . . . . . 27
   2.5.7   Support Counters For Packets Dropped By Anti-spoofing  . . 28
   2.6     Rate Limiting Requirements . . . . . . . . . . . . . . . . 28
   2.6.1   Support Rate Limiting  . . . . . . . . . . . . . . . . . . 28
   2.6.2   Support Directional Application Rate Limiting Per
           Interface  . . . . . . . . . . . . . . . . . . . . . . . . 29
   2.6.3   Support Rate Limiting Based on State . . . . . . . . . . . 29
   2.7     Basic Filtering Capabilities . . . . . . . . . . . . . . . 30
   2.7.1   Ability to Filter Traffic  . . . . . . . . . . . . . . . . 30
   2.7.2   Ability to Filter Traffic TO the Device  . . . . . . . . . 30
   2.7.3   Ability to Filter Traffic THROUGH the Device . . . . . . . 30
   2.7.4   Ability to Filter Without Performance Degradation  . . . . 31
   2.7.5   Support Route Filtering  . . . . . . . . . . . . . . . . . 31
   2.7.6   Ability to Specify Filter Actions  . . . . . . . . . . . . 31
   2.7.7   Ability to Log Filter Actions  . . . . . . . . . . . . . . 32
   2.8     Packet Filtering Criteria  . . . . . . . . . . . . . . . . 33
   2.8.1   Ability to Filter on Protocols . . . . . . . . . . . . . . 33
   2.8.2   Ability to Filter on Addresses . . . . . . . . . . . . . . 33
   2.8.3   Ability to Filter on Protocol Header Fields  . . . . . . . 33
   2.8.4   Ability to Filter Inbound and Outbound . . . . . . . . . . 34
   2.9     Packet Filtering Counter Requirements  . . . . . . . . . . 34
   2.9.1   Ability to Accurately Count Filter Hits  . . . . . . . . . 34
   2.9.2   Ability to Display Filter Counters . . . . . . . . . . . . 35
   2.9.3   Ability to Display Filter Counters per Rule  . . . . . . . 35
   2.9.4   Ability to Display Filter Counters per Filter
           Application  . . . . . . . . . . . . . . . . . . . . . . . 36
   2.9.5   Ability to Reset Filter Counters . . . . . . . . . . . . . 36
   2.9.6   Filter Counters Must Be Accurate . . . . . . . . . . . . . 37
   2.10    Other Packet Filtering Requirements  . . . . . . . . . . . 37
   2.10.1  Ability to Specify Filter Log Granularity  . . . . . . . . 37
   2.11    Event Logging Requirements . . . . . . . . . . . . . . . . 37
   2.11.1  Logging Facility Uses Protocols Subject To Open Review . . 37
   2.11.2  Ability to Log to Remote Server  . . . . . . . . . . . . . 38
   2.11.3  Ability to Log Locally . . . . . . . . . . . . . . . . . . 39
   2.11.4  Ability to Maintain Accurate System Time . . . . . . . . . 39
   2.11.5  Display Timezone And UTC Offset  . . . . . . . . . . . . . 39
   2.11.6  Default Timezone Should Be UTC . . . . . . . . . . . . . . 40
   2.11.7  Logs Must Be Timestamped . . . . . . . . . . . . . . . . . 40
   2.11.8  Logs Contain Untranslated IP Addresses . . . . . . . . . . 41
   2.12    Authentication, Authorization, and Accounting (AAA)
           Requirements . . . . . . . . . . . . . . . . . . . . . . . 42
   2.12.1  Authenticate All User Access . . . . . . . . . . . . . . . 42
   2.12.2  Support Authentication of Individual Users . . . . . . . . 42
   2.12.3  Support Simultaneous Connections . . . . . . . . . . . . . 43
   2.12.4  Ability to Disable All Local Accounts  . . . . . . . . . . 43
   2.12.5  Support Centralized User Authentication Methods  . . . . . 43
   2.12.6  Support Local User Authentication Method . . . . . . . . . 44
   2.12.7  Support Configuration of Order of Authentication



Jones, Editor            Expires June 15, 2004                  [Page 3]

Internet-Draft     Operational Security Requirements       December 2003


           Methods  . . . . . . . . . . . . . . . . . . . . . . . . . 44
   2.12.8  Ability To Authenticate Without Plaintext Passwords  . . . 45
   2.12.9  No Default Passwords . . . . . . . . . . . . . . . . . . . 45
   2.12.10 Passwords Must Be Explicitly Configured Prior To Use . . . 46
   2.12.11 Ability to Define Privilege Levels . . . . . . . . . . . . 46
   2.12.12 Ability to Assign Privilege Levels to Users  . . . . . . . 47
   2.12.13 Default Privilege Level Must Be 'None' . . . . . . . . . . 47
   2.12.14 Change in Privilege Levels Requires Re-Authentication  . . 48
   2.12.15 Support Recovery Of Privileged Access  . . . . . . . . . . 48
   2.12.16 Send Accounting Records To Remote Servers  . . . . . . . . 49
   2.12.17 Accounting Records To Be Sent  . . . . . . . . . . . . . . 49
   2.12.18 Do Not Log Passwords . . . . . . . . . . . . . . . . . . . 50
   2.13    Layer 2 Devices Must Meet Higher Layer Requirements  . . . 50
   2.14    Security Features Must Not Cause Operational Problems  . . 51
   2.15    Security Features Should Have Minimal Performance
           Impact . . . . . . . . . . . . . . . . . . . . . . . . . . 51
   3.      Documentation Requirements . . . . . . . . . . . . . . . . 53
   3.1     Identify Services That May Be Listening  . . . . . . . . . 53
   3.2     Document Service Defaults  . . . . . . . . . . . . . . . . 53
   3.3     Document Service Activation Process  . . . . . . . . . . . 54
   3.4     Document Command Line Interface  . . . . . . . . . . . . . 54
   3.5     'Console' Default Communication Profile Documented . . . . 54
   4.      Assurance Requirements . . . . . . . . . . . . . . . . . . 55
   4.1     Identify Origin of IP Stack  . . . . . . . . . . . . . . . 55
   4.2     Identify Origin of Operating System  . . . . . . . . . . . 55
   5.      Security Considerations  . . . . . . . . . . . . . . . . . 56
           Normative References . . . . . . . . . . . . . . . . . . . 57
           Non-normative References . . . . . . . . . . . . . . . . . 60
           Author's Address . . . . . . . . . . . . . . . . . . . . . 60
   A.      Requirement Profiles . . . . . . . . . . . . . . . . . . . 61
   A.1     Minimum Requirements Profile . . . . . . . . . . . . . . . 61
   A.2     Layer 3 Network Edge Profile . . . . . . . . . . . . . . . 64
   B.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 66
           Intellectual Property and Copyright Statements . . . . . . 67

















Jones, Editor            Expires June 15, 2004                  [Page 4]

Internet-Draft     Operational Security Requirements       December 2003


1. Introduction

1.1 Goals

   This document defines a list of operational security requirements for
   the infrastructure of large IP networks (routers and switches) which
   are considered to be best current practice (BCP). 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 insure 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 IP networks (e.g. routers and switches).
   Certain groups (or "profiles", see below) apply only in specific
   situations (e.g. edge-only).

   The following devices are explicitly out of scope: General purpose
   hosts that do not transit traffic including infrastructure hosts such
   as name/time/log/AAA servers, etc., unmanaged devices, customer
   managed devices (e.g.  firewalls, Intrusion Detection System,
   dedicated VPN devices, etc.), and SOHO devices. 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.

   Confidentiality and integrity of customer data are outside the scope.

   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)




Jones, Editor            Expires June 15, 2004                  [Page 5]

Internet-Draft     Operational Security Requirements       December 2003


   o  traffic goes where its 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

   The following assumptions are made:

   o  Devices are physically secure.

   o  The management infrastructure (AAA/DNS/log server, SNMP management
      stations, etc.) is secure.


1.5 Intended Audience

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

1.6 Format

   The individual requirements are listed in one of the three sections
   listed 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  The Requirement (What)

   o  The Justification (Why)

   o  Examples (How)




Jones, Editor            Expires June 15, 2004                  [Page 6]

Internet-Draft     Operational Security Requirements       December 2003


   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
   [I-D.iab-secmech]. 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, the 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 this document will be used for the following
   purposes:

   Security Capability Checklist. The requirements may be used as a
      checklist when evaluating networked products.

   Composing Profiles. Composing profiles from different subsets to
      describe the needs of different devices, organizations, and
      operating environments.

   Communicating Requirements. To assist operators to clearly
      communicate security requirements.

   Basis For Testing and Certification. As a  basis for testing and
      certification of security features of networked products.


1.8 Definitions

   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, Editor            Expires June 15, 2004                  [Page 7]

Internet-Draft     Operational Security Requirements       December 2003


   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 RS-232 serial port which has, for the past 30 or more
      years, provided a simple, stable, reliable, well-understood
      management and nearly ubiquitous interface to network devices.
      Again, these requirements are intended primarily to codify the
      benefits provided by that venerable interface, not to preclude
      other mechanisms that meet all the same requirements.

   Filter

      In this document, a "filter" is defined as a group of one or more
      rules where each rule specifies one or more match criteria as
      specified in Section 2.8.

   In-Band management.

      "In-Band management" is defined as any management done over the
      same channels and interfaces used for user/customer data. Examples
      would include using SSH for management via customer or Internet
      facing network interfaces.

   High Resolution Time.

      "High resolution time" is defined in this document as "time having
      a resolution greater than one second" (e.g. milliseconds).

   IP.

      Unless otherwise indicated, "IP" refers to IPv4.

   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, Editor            Expires June 15, 2004                  [Page 8]

Internet-Draft     Operational Security Requirements       December 2003


   Open Review.

      "Open review" refers to processes designed to generate public
      discussion and review of proposed technical solutions such as data
      communications protocols and encryption 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".

   Passwords.

      A number of requirements refer to "passwords".  This should be
      interpreted broadly to refer to any authentication token including
      pass-phrases, shared secrets, private keys, etc.

   Service.

      A number of requirements refer to "services". For the purposes of
      this document a "services" 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 confidentially 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.



Jones, Editor            Expires June 15, 2004                  [Page 9]

Internet-Draft     Operational Security Requirements       December 2003


   Single-Homed Network.

      A "single-homed network" is defined as one for which

      *  There is only one (logical) upstream connection

      *  Routing is symmetric

   Spoofed Packet.

      A "spoofed packet" is defined as a "packet having a source address
      that, by application of the current forwarding tables, would not
      have its return traffic routed back through the interface on which
      it was received."





































Jones, Editor            Expires June 15, 2004                 [Page 10]

Internet-Draft     Operational Security Requirements       December 2003


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 confidentially for all network traffic and protocols
      used to support management functions.  This MUST include at least
      protocols used for configuration, monitoring, configuration
      backup, logging, time synchronization, authentication, and
      routing. This requirement MAY be satisfied using either In-Band or
      Out-of-Band mechanisms as defined in Section 2.2 and Section 2.3.

   Justification. Integrity protection is required to insure 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 using the device.

   Examples. Different mechanisms may be used with different protocols
      to satisfy this requirement. Secure management can be achieved by
      the use of protocols that use encryption to ensure integrity and
      confidentiality, by the use of protocols which depend on lower
      layers (TLS [RFC2246] or IPsec [RFC2401]) for security, or by the
      use of out-of-band management. For example

      Protocols that use encryption: SSH, SFTP, SNMPv3, BGP, NTP,
         Kerberos.

      Protocols that do not use encryption: telnet, FTP, TFTP, SNMPv1,
         syslog.

   Warnings. The use of encryption does not guarantee that the protocol
      is secure.


2.2 In-Band Management Requirements

   This section lists security requirements for devices that are managed
   In-band. 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



Jones, Editor            Expires June 15, 2004                 [Page 11]

Internet-Draft     Operational Security Requirements       December 2003


      unmanageable

   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

   o  Since the same networking code and interfaces are shared for
      management and customer data, it is not possible to isolate
      management functions from failures in other areas. (For example, a
      "magic packet" or buffer overrun that causes the data forwarding
      portions of a router to crash will also likely make it impossible
      to manage.  This would not necessarily be the case if the
      management and data forwarding elements were completely separated)


2.2.1 Use Encryption Algorithms Subject To Open Review

   Requirement. If encryption is used to provide secure management
      channels, then it MUST support encryption algorithms that are
      subject to "open review" as defined in Section 1.8. These SHOULD
      be used by default. The device MAY optionally support algorithms
      that are not open to review.

   Justification. Encryption algorithms that have not been subjected to
      widespread, extended public/peer review are more likely to have
      undiscovered weaknesses or flaws than open standards and publicly
      reviewed algorithms. Network operators may have need or desire to
      use non-open encryption algorithms.  They should be allowed to
      evaluate the trade-offs and make an informed choice between open
      and non-open encryption. 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] 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.



Jones, Editor            Expires June 15, 2004                 [Page 12]

Internet-Draft     Operational Security Requirements       December 2003


      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 Encryption

   Requirement. If encryption is used to provide secure management
      channels 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] 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.

      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 encryption and the
      strength of encryption used.

      This document explicitly does not attempt to make any
      authoritative statement about what key lengths constitute "strong"
      encryption. See [I-D.orman-public-key-lengths] for help in
      determining appropriate key lengths. Also see [Schneier] chapter 7
      for a discussion of key lengths.





Jones, Editor            Expires June 15, 2004                 [Page 13]

Internet-Draft     Operational Security Requirements       December 2003


2.2.3 Use Encryption in Protocols Subject To Open Review

   Requirement. If encryption 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
      encryption in protocols that are not open to review.

   Justification. Protocols that have not been subjected to widespread,
      extended public/peer review are more likely to have undiscovered
      weaknesses or flaws than open standards and publicly reviewed
      protocols Network operators may have need or desire to use
      non-open protocols They should be allowed to evaluate the
      trade-offs and make an informed choice between open and non-open
      protocols.

   Examples. See TLS [RFC2246] and IPsec [RFC2401].

   Warnings.

      Note that open review is necessary but may not be sufficient.  It
      is perfectly possible for an openly reviewed protocol to misuse
      (or not use) encryption.


2.2.4 Allow Selection of Encryption Parameters

   Requirement. The device SHOULD allow the operator to select
      encryption parameters. This SHOULD include key lengths and
      algorithms.

   Justification. Encryption 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 encryption 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, Editor            Expires June 15, 2004                 [Page 14]

Internet-Draft     Operational Security Requirements       December 2003


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.

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 control planes.

   Justification. There are times when the device *must* be managed or
      configured, even when the network is unavailable, routing and
      network interfaces are incorrectly configured, the IP stack and/or
      operating system may not be working (or may be vulnerable to
      recently discovered exploits that make their use impossible/
      inadvisable), or when high bandwidth paths to the device are
      unavailable.  In such situations, a console interface can provide
      a way to manage and configure the device.

   Examples.

      An RS232 (EIA232) interface that provides the capability to load
      new versions of the system software and to perform configuration
      via a command line interface.  RS232 interfaces are ubiquitous and
      well understood.

      A simple embedded device that provides management and
      configuration access via an Ethernet or USB interface.

   Warnings.

      As of this writing, RS-232 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
         RS2323.

      *  Availability.  It works even in the presence of network
         failure.



Jones, Editor            Expires June 15, 2004                 [Page 15]

Internet-Draft     Operational Security Requirements       December 2003


      *  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.


2.3.2 'Console' Has A Simple Default Communication Profile

   Requirement. The device MUST support a simple default profile of
      communications parameters on the 'console'.

   Justification. A simple, standard profile minimizes confusion and
      maximizes the chances of successful and well understood recovery
      practices.

   Examples.

         The following is a profile widely used for RS232 console
         connections:

         +  only required signals are Transmit Data (TD), Receive Data
            (RD) and Signal Ground (SG).

         +  Other signals, are not required (e.g. RTS, CTS, DSR, etc.).

         +  Data Carrier Detect (DCD) is not be required to create a
            session, but existing sessions terminate on HIGH to LOW or
            HIGH to FLOAT transitions to prevent unauthorized users from
            gaining access to existing sessions.

         +  The default settings are 9600bps, 8 bit data, no parity, one
            stop-bit (9600 8n1).

   Warnings. The default RS232 profile described above does not support
      hardware flow control.


2.3.3 'Console' Communication Profile Must Support Reset





Jones, Editor            Expires June 15, 2004                 [Page 16]

Internet-Draft     Operational Security Requirements       December 2003


   Requirement. If it is possible to change the default console
      communication profile, then there MUST be a method defined and
      published for returning to the default configuration.

   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.

      A physical toggle switch on the device might provide a way of
      resetting the default parameters.  Another method might be to send
      a break or a predefined character sequence on a serial line.

   Warnings. None.


2.3.4 'Console' requires minimal functionality of attached devices.

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

   Justification. The purpose of having the console interface is to have
      a management interface that can be made to work quickly at all
      times.  Requiring complex or nonstandard behavior on the part of
      attached devices reduces the likelihood that the console will
      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.5 '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.  In the event
      of fall-back AUTHENTICATION, the interface SHOULD either implement
      a locally defined AUTHORIZATION profile or consider all commands
      to be AUTHORIZED. This mechanism SHOULD be implemented as a



Jones, Editor            Expires June 15, 2004                 [Page 17]

Internet-Draft     Operational Security Requirements       December 2003


      fall-back if the preferred authentication method is not "LOCAL".

   Justification. It does little good to have a console interface on a
      device if you cannot get into the device with it when the network
      is not working.

   Examples. Some devices which use TACACS or RADIUS for authentication
      will fall back to a local account if the TACACS or RADIUS server
      does not reply to an authentication request.

   Warnings. This requirement represents a trade-off between being able
      to manage the device (functionality) and security. There are many
      ways to implement this which would provide reduced security for
      the device, e.g. a back door for unauthorized access. Local policy
      should be consulted to determine if "fail open" or "fail closed"
      is the correct stance.  The implications of "fail closed" (e.g.
      not being able to manage a device) should be fully considered.


2.3.6 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.7 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.6 then the device MUST
      NOT forward traffic between the management plane and
      non-management plane interfaces.



Jones, Editor            Expires June 15, 2004                 [Page 18]

Internet-Draft     Operational Security Requirements       December 2003


   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.3.8 Provide Separate Resources For The Management Plane

   Requirement. If the device implements separate network interface(s)
      for the management plane per Section 2.3.6 then the device SHOULD
      provide separate resources and use separate software for different
      classes of interface.

   Justification. The use of separate resources and system software
      allows for fault isolation and increased reliability.  If
      something (a hacker sending a DoS flood or exercising a buffer
      overrun) takes out the forwarding plane, the management plane is
      likely to keep working, which will facilitate recovery.
      Likewise, if something causes the management plane to stop
      working, it is possible that the forwarding plane will keep doing
      its job (forwarding packets).

   Examples. Resources which should be separate include hardware
      (memory, processor), data (forwarding table), and software (OS, IP
      stack).

   Warnings. None.


2.4 Configuration and Management Interface Requirements

   This section lists requirements that document current best practice
   in 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 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





Jones, Editor            Expires June 15, 2004                 [Page 19]

Internet-Draft     Operational Security Requirements       December 2003


   Requirement. The Command Line Interface (CLI) or equivalent MUST
      allow complete access to all configuration and management
      functions.

   Justification. Restricted or incomplete access to configuration or
      management functions may make it impossible to perform necessary
      tasks.

   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.  The scripting capability MUST NOT be
      restricted to use with one specific scripting language.

   Justification. Scripting is necessary when the number of managed
      devices is large and/or when changes must be implemented quickly.
      The ability to script configuration functions provides operators
      with the ability to implement solutions to problems not foreseen
      or addressed by the vendor.

   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.


2.4.3 CLI Supports Management Over 'Slow' Links






Jones, Editor            Expires June 15, 2004                 [Page 20]

Internet-Draft     Operational Security Requirements       December 2003


   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.

   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.


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



Jones, Editor            Expires June 15, 2004                 [Page 21]

Internet-Draft     Operational Security Requirements       December 2003


      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.).

   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 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. will 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).

   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 a:

      RS-232 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, Editor            Expires June 15, 2004                 [Page 22]

Internet-Draft     Operational Security Requirements       December 2003


      FLASH The device could support booting from flash memory cards.

   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.
      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.

   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.


2.4.8 Support Text Configuration Files





Jones, Editor            Expires June 15, 2004                 [Page 23]

Internet-Draft     Operational Security Requirements       December 2003


   Requirement. The device MUST provide a means to remotely save a copy
      of the system configuration file(s) in a textual format.  It MUST
      NOT be necessary to use a proprietary program to view the
      configuration. The configuration MUST also be viewable as text on
      the device itself. Sensitive information such as passwords that
      could be used to compromise the security of the device MAY be
      excluded from the saved configuration.

   Justification. Having configurations as text is necessary to enable
      off-line audits of the system configuration.  Having them in
      simple, non-proprietary formats also facilitates automation of
      configuration checking.

   Examples. A 7-bit ASCII configuration file that shows the current
      settings of the various configuration options wold 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.

   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.


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 interfaces on which each service is listening.

      *  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, Editor            Expires June 15, 2004                 [Page 24]

Internet-Draft     Operational Security Requirements       December 2003


   Examples. If, for example, the device is listening for SNMP on all
      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 external
      services listening.

   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 Listening Services Should Be Off By Default

   Requirement. "Services" SHOULD be off by default.  The user SHOULD
      have to take explicit actions to enable any such services.

   Justification. Open ports have the potential to expose
      vulnerabilities. The user, not the vendor, should decide which
      services are required and what risks to accept.  This will also
      prevent systems from being compromised through the misuse of
      services which the user was unaware were enabled.

   Examples. If the device supports SSH, HTTP, telnet and SNMP, in the
      default configuration they should all be disabled.

   Warnings. "Default deny" is a best practice in pure security terms.
      It may violate operator or vendor assumptions or possibly some
      RFCs.


2.5.4 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 a list of addresses and netblocks.  It MUST also
      support configuration of binding services to any interface local
      to the device, physical or non-physical (e.g. "loopbacks").



Jones, Editor            Expires June 15, 2004                 [Page 25]

Internet-Draft     Operational Security Requirements       December 2003


   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
      because they provide a stable, routable address.  Services bound
      to physical interface addresses might become unreachable if the
      associated hardware goes down, is removed, etc.

      This requirement makes it possible restrict access to management
      services using routing. Management services may be bound only to
      loopback interfaces.  The looopback interfaces may be addressed
      out of netblocks 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 on
      every interface or to every address configured on the device.

   Warnings. None.


2.5.5 Ability to Control Service Source Address

   Requirement. The device MUST provide a means that allows the user to
      specify the source address 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, Editor            Expires June 15, 2004                 [Page 26]

Internet-Draft     Operational Security Requirements       December 2003


   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.

      Also note that [I-D.iab-secmech] lists address-based
      authentication as an "insecurity mechanism".   Address based
      authentication should be replaced or augmented by other mechanisms
      wherever possible.


2.5.6 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.  . This option MUST work in the
      presence of dynamic routing and dynamically assigned addresses.

   Justification. See [RFC2867] Network Ingress Filtering.

   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



Jones, Editor            Expires June 15, 2004                 [Page 27]

Internet-Draft     Operational Security Requirements       December 2003


      checked against the current routing tables and dropped if they
      would not be forwarded back through the interface on which they
      were received.

      For an example implementation, see the "verrevpath" option to the
      "ipfw" firewall on FreeBSD and similar systems.

   Warnings. None.


2.5.7 Support Counters For Packets Dropped By Anti-spoofing

   Requirement.

      The device MUST provide accurate, per-interface counts of spoofed
      packets dropped by 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.


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 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.

   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



Jones, Editor            Expires June 15, 2004                 [Page 28]

Internet-Draft     Operational Security Requirements       December 2003


      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.


2.6.2 Support Directional Application Rate Limiting Per Interface

   Requirement. The device MUST provide support to 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 on all
      TCP state 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, Editor            Expires June 15, 2004                 [Page 29]

Internet-Draft     Operational Security Requirements       December 2003


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
      SNMP and SSH traffic from an authorized management segment
      directed to the device itself, while dropping all other traffic
      addressed to the device.

   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, firewalls,
      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



Jones, Editor            Expires June 15, 2004                 [Page 30]

Internet-Draft     Operational Security Requirements       December 2003


      described in [RFC2827] provides one example of the use of this
      capability.

   Warnings. None.


2.7.4 Ability to Filter Without Performance Degradation

   Requirement. The device MUST provide a means to filter packets
      without performance degradation. The device MUST be able to filter
      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.

   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. This requirement most likely implies a
      hardware-based solution (ASIC).

   Warnings. Without hardware based filtering, it may be possible for
      the implementation of filters to degrade the performance of the
      device or to cause it to cease functioning.


2.7.5 Support Route Filtering

   Requirement. The device MUST provide a means to filter routing
      updates for all supported dynamic routing protocols.

   Justification. See [RFC3013] and section 3.2 of [RFC2196].

   Examples. Operators may wish to ignore advertisements for routes to
      addresses allocated for private Internets.

   Warnings. None.


2.7.6 Ability to Specify Filter Actions






Jones, Editor            Expires June 15, 2004                 [Page 31]

Internet-Draft     Operational Security Requirements       December 2003


   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 ports, source and
      destination IP address, which network element forwarded the packet
      (interface, MAC address or other layer 2 information that
      identifies the previous hop source of the packet), and time-stamp
      to millisecond accuracy.

      Logging of filter actions is subject to the requirements of
      Section 2.11.

   Justification. Logging is essential for auditing, incident response,
      and operations.






Jones, Editor            Expires June 15, 2004                 [Page 32]

Internet-Draft     Operational Security Requirements       December 2003


   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 protocol.

   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.


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 of all other protocols



Jones, Editor            Expires June 15, 2004                 [Page 33]

Internet-Draft     Operational Security Requirements       December 2003


      supported at layer 3 and 4.   It MAY support 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).
      Another common 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, Editor            Expires June 15, 2004                 [Page 34]

Internet-Draft     Operational Security Requirements       December 2003


   Justification. Accurate counting of filter rule matches is important
      because it shows the magnitude/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 IPS's 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.


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.





Jones, Editor            Expires June 15, 2004                 [Page 35]

Internet-Draft     Operational Security Requirements       December 2003


   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
      "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.

   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



Jones, Editor            Expires June 15, 2004                 [Page 36]

Internet-Draft     Operational Security Requirements       December 2003


      traffic indicative of the worm has ceased.

   Warnings. None.


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^64 - 1
      values without overflowing.

   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)
      wold 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.

   Warnings. None.


2.11 Event Logging Requirements

2.11.1 Logging Facility Uses Protocols Subject To Open Review






Jones, Editor            Expires June 15, 2004                 [Page 37]

Internet-Draft     Operational Security Requirements       December 2003


   Requirement. The device MUST provide a logging facility that is based
      on protocols subject to open review 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. The syslog protocol described in [RFC3164] meets this
      requirement.

   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:

      *  Implement [RFC3164]

      *  Consider implementing [RFC3195]


2.11.2 Ability to Log to Remote Server

   Requirement. The device MUST be capable of logging to a remote
      server. It SHOULD be able to log to multiple servers.

   Justification. External logging allows the storage of large,
      persistent logs that may not be possible with local (on the
      device) logging.

   Examples. One example of a remote log server would be a host running
      a syslog server.  See [RFC3164].

   Warnings. High volumes of logging may generate excessive network
      traffic and/or compete for scarce memory and CPU resources on the
      device.






Jones, Editor            Expires June 15, 2004                 [Page 38]

Internet-Draft     Operational Security Requirements       December 2003


2.11.3 Ability to Log Locally

   Requirement.

      It SHOULD be possible to log locally on the device itself.

   Justification. 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.4 Ability to Maintain Accurate System Time

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

   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.5 Display Timezone And UTC Offset





Jones, Editor            Expires June 15, 2004                 [Page 39]

Internet-Draft     Operational Security Requirements       December 2003


   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.


2.11.6 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.7 Logs Must Be Timestamped

   Requirement. The device MUST time-stamp all log messages.  The
      time-stamp MUST be accurate to within a second or less.  The
      time-stamp MUST include a timezone.

   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.






Jones, Editor            Expires June 15, 2004                 [Page 40]

Internet-Draft     Operational Security Requirements       December 2003


   Examples. This requirement MAY be satisfied by writing timestamps
      into syslog messages.

   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.8 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 a 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.

      *  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



Jones, Editor            Expires June 15, 2004                 [Page 41]

Internet-Draft     Operational Security Requirements       December 2003


         organization owned the system(s) in question at the time.


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.


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.







Jones, Editor            Expires June 15, 2004                 [Page 42]

Internet-Draft     Operational Security Requirements       December 2003


2.12.3 Support Simultaneous Connections

   Requirement. The device SHOULD 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.

   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

   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.

   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



Jones, Editor            Expires June 15, 2004                 [Page 43]

Internet-Draft     Operational Security Requirements       December 2003


      to the system by authorized personnel.

   Examples.

      This requirement can be satisfied through the use of DIAMETER
      [RFC3588], TACACS+ [RFC1492], RADIUS [RFC3588], or Kerberos
      [RFC1510].

      The secure management requirements (Section 2.1.1) apply to AAA.
      See [RFC3539] and See [RFC3588] for discussions of the issues and
      options for securing RADIUS and other authentication protocols.

   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.

   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.



Jones, Editor            Expires June 15, 2004                 [Page 44]

Internet-Draft     Operational Security Requirements       December 2003


   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.

   Justification. Plain-text passwords can be easily observed using
      packet sniffers on shared networks. See [RFC1704] and
      [I-D.iab-secmech]  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".

   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.




Jones, Editor            Expires June 15, 2004                 [Page 45]

Internet-Draft     Operational Security Requirements       December 2003


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.

   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
      parameters. Note that privilege levels may be defined locally on
      the device or on centralized authentication servers.






Jones, Editor            Expires June 15, 2004                 [Page 46]

Internet-Draft     Operational Security Requirements       December 2003


   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 the device.  Privilege level
      determines which functions a user is allowed to execute.   Also
      see 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 MUST 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
      Section 2.4.5 or recovery of authorized access Section 2.12.15.

   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.





Jones, Editor            Expires June 15, 2004                 [Page 47]

Internet-Draft     Operational Security Requirements       December 2003


   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 insures 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.


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



Jones, Editor            Expires June 15, 2004                 [Page 48]

Internet-Draft     Operational Security Requirements       December 2003


         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.


2.12.16 Send Accounting Records To Remote Servers

   Requirement. The device MUST support transmission of accounting
      records 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
      RADIUS,TACACS+, or syslog.

   Warnings.

      Note that there may be privacy or legal considerations when
      logging/monitoring user activity.


2.12.17 Accounting Records To Be Sent

   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



Jones, Editor            Expires June 15, 2004                 [Page 49]

Internet-Draft     Operational Security Requirements       December 2003


      *  Device status changes

   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.

      Note that there may be privacy or legal considerations when
      logging/monitoring user activity.


2.12.18 Do Not Log 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.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.






Jones, Editor            Expires June 15, 2004                 [Page 50]

Internet-Draft     Operational Security Requirements       December 2003


   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 MUST NOT cause severe operational
      problems.

   Justification. Security features which cause operational problems may
      leave the operator with no mechanism for enforcing appropriate
      policy.

   Examples. Some examples of severe operational problems include:

      *  crashes the device

      *  makes the device unmanageable

      *  causes the loss of data

      *  consumes excessive resources (CPU, memory, bandwidth)

   Warnings. None.


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 will 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.



Jones, Editor            Expires June 15, 2004                 [Page 51]

Internet-Draft     Operational Security Requirements       December 2003


      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, Editor            Expires June 15, 2004                 [Page 52]

Internet-Draft     Operational Security Requirements       December 2003


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.

   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.

   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.







Jones, Editor            Expires June 15, 2004                 [Page 53]

Internet-Draft     Operational Security Requirements       December 2003


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.

   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.





Jones, Editor            Expires June 15, 2004                 [Page 54]

Internet-Draft     Operational Security Requirements       December 2003


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.


4.1 Identify Origin of IP Stack

   Requirement. The vendor MUST 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 MUST 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, Editor            Expires June 15, 2004                 [Page 55]

Internet-Draft     Operational Security Requirements       December 2003


5. Security Considerations

   Security is the subject matter of this entire memo.
















































Jones, Editor            Expires June 15, 2004                 [Page 56]

Internet-Draft     Operational Security Requirements       December 2003


Normative References

   [ANSI.X9-52.1998]
              American National Standards Institute, "Triple Data
              Encryption Algorithm Modes of Operation", ANSI X9.52,
              1998.

   [FIPS.186-1.1998]
              National Institute of Standards and Technology, "Digital
              Signature Standard", FIPS PUB 186-1, December 1998,
              <http://csrc.nist.gov/fips/fips1861.pdf>.

   [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.

   [RFC-INDEX]
              IESG and IETF, "The IETF RFC Series", <http://
              www.ietf.org/iesg/1rfc_index.txt>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC0922]  Mogul, J., "Broadcasting Internet datagrams in the
              presence of subnets", STD 5, RFC 922, October 1984.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1492]  Finseth, C., "An Access Control Protocol, Sometimes Called
              TACACS", RFC 1492, July 1993.

   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
              Authentication Service (V5)", RFC 1510, September 1993.



Jones, Editor            Expires June 15, 2004                 [Page 57]

Internet-Draft     Operational Security Requirements       December 2003


   [RFC1704]  Haller, N. and R. Atkinson, "On Internet Authentication",
              RFC 1704, October 1994.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
              1812, June 1995.

   [RFC1858]  Ziemba, G., Reed, D. and P. Traina, "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              October 1995.

   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
              RFC 1948, May 1996.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
              Keyed-Hashing for Message Authentication", RFC 2104,
              February 1997.

   [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", RFC 2196, September
              1997.

   [RFC2246]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
              and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
              January 1999.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2644]  Senie, D., "Changing the Default for Directed Broadcasts
              in Routers", BCP 34, RFC 2644, August 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.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2865, June 2000.

   [RFC2867]  Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
              Modifications for Tunnel Protocol Support", RFC 2867, June
              2000.




Jones, Editor            Expires June 15, 2004                 [Page 58]

Internet-Draft     Operational Security Requirements       December 2003


   [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.

   [RFC3360]  Floyd, S., "Inappropriate TCP Resets Considered Harmful",
              BCP 60, RFC 3360, August 2002.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC3539]  Aboba, B. and J. Wood, "Authentication, Authorization and
              Accounting (AAA) Transport Profile", RFC 3539, June 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.


























Jones, Editor            Expires June 15, 2004                 [Page 59]

Internet-Draft     Operational Security Requirements       December 2003


Non-normative References

   [I-D.iab-secmech]
              Bellovin, S., Kaufman, C. and J. Schiller, "Security
              Mechanisms for the Internet", draft-iab-secmech-03 (work
              in progress), July 2003.

   [I-D.orman-public-key-lengths]
              Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys",
              draft-orman-public-key-lengths-06 (work in progress),
              December 2003.

   [Schneier]
              Schneier, B., "Applied Crytography, 2nd Ed., Publisher
              John Wiley & Sons, Inc.", 1996.


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: gmjones@mitre.org























Jones, Editor            Expires June 15, 2004                 [Page 60]

Internet-Draft     Operational Security Requirements       December 2003


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 Encryption in Protocols Subject To Open Review

   o  Use Encryption Algorithms Subject To Open Review

   o  Use Strong Encryption

   o  Allow Selection of Encryption Parameters

   o  Support a 'Console' interface

   o  'Console' Has A Simple Default Communication Profile

   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  Provide Separate Resources For The Management Plane

   o  CLI Provides Access to All Configuration and Management Functions

   o  CLI Supports Scripting of Configuration



Jones, Editor            Expires June 15, 2004                 [Page 61]

Internet-Draft     Operational Security Requirements       December 2003


   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  Listening Services Should Be Off By Default

   o  Ability to Control Service Bindings for Listening Services

   o  Ability to Control Service Source Address

   o  Support Automatic Anti-spoofing for Single-Homed Networks

   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 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




Jones, Editor            Expires June 15, 2004                 [Page 62]

Internet-Draft     Operational Security Requirements       December 2003


   o  Ability to Display Filter Counters

   o  Ability to Display Filter Counters per Rule

   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  Ability to Log to Remote Server

   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  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




Jones, Editor            Expires June 15, 2004                 [Page 63]

Internet-Draft     Operational Security Requirements       December 2003


   o  Ability to Assign Privilege Levels to Users

   o  Default Privilege Level Must Be 'None'

   o  Change in Privilege Levels Requires Re-Authentication

   o  Support Recovery Of Privileged Access

   o  Send Accounting Records To Remote Servers

   o  Accounting Records To Be Sent

   o  Do Not Log 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.




Jones, Editor            Expires June 15, 2004                 [Page 64]

Internet-Draft     Operational Security Requirements       December 2003


   o  Support Automatic Anti-spoofing for Single-Homed Networks

   o  Support Counters For Packets Dropped By Anti-spoofing

   o  Support Rate Limiting

   o  Support Directional Application Rate Limiting Per Interface

   o  Support Rate Limiting Based on State

   o  Ability to Filter Traffic THROUGH the Device








































Jones, Editor            Expires June 15, 2004                 [Page 65]

Internet-Draft     Operational Security Requirements       December 2003


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  UUNET's entire network security team (past and present): 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, Michael H. Behringer, Matt Bishop, Scott Blake, Randy
      Bush, Pat Cain, Steven Christey, Owen Delong, Sean Donelan, Robert
      Elmore, Barbara Fraser, Barry Greene, Dan Hollis, Jeffrey
      Hutzelman, Merike Kaeo, John Kristoff, Chris Liljenstolpe, James
      W. Laferriere, Jared Mauch, Mike O'Connor, Alan Paller, Rob
      Pickering, Gregg Schudel, Don Smith, Rodney Thayer, David Walters,
      Joel N. Weber II, 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.

   o  Apologies to those who commented on/contributed to the document
      and were not listed...contact the editor to be credited in future
      versions.

   Version: $Id: draft-jones-opsec-03.cpp,v 1.9 2003/12/16 04:01:47
   george Exp $




Jones, Editor            Expires June 15, 2004                 [Page 66]

Internet-Draft     Operational Security Requirements       December 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Jones, Editor            Expires June 15, 2004                 [Page 67]

Internet-Draft     Operational Security Requirements       December 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Jones, Editor            Expires June 15, 2004                 [Page 68]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/